than not knowing what they are at all. Perhaps they should have their own
type category? Hard to say. In the meantime, doing it this way allows
SELECT 'unknown' || 'unknown' to continue being resolved as textcat,
instead of spitting out an ambiguous-operator error.
parse node types. This allows these statements to be placed in a plpgsql
function. Also, see to it that statement types not handled by the copy
logic will draw an appropriate elog(ERROR), instead of leaving a null
pointer that will cause coredump later on. More utility statements could
be added if anyone felt like turning the crank.
Add a random number generator and seed setter (random(), SET SEED)
Fix up the interval*float8 math to carry partial months
into the time field.
Add float8*interval so we have symmetry in the available math.
Fix the parser and define.c to accept SQL92 types as field arguments.
Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is
necessary to allow...
Bit/varbit support in contrib/bit cleaned up to compile and load
cleanly. Still needs some work before final release.
Implement the "SOME" keyword as a synonym for "ANY" per SQL92.
Implement ascii(text), ichar(int4), repeat(text,int4) to help
support the ODBC driver.
Enable the TRUNCATE() function mapping in the ODBC driver.
Ensure that outer tuple link needed for inner indexscan qual evaluation
gets set in the EvalPlanQual case. This stops coredump, but we still
have resource leaks due to failure to clean up EvalPlanQual properly...
xact abort state in pg_exec_query_dest, we should continue scanning the
querytree list, on the off chance that one of the later queries in the
string is COMMIT or ROLLBACK.
would crash, due to premature invocation of SetQuerySnapshot(). Clean
up problems with handling of multiple queries by splitting
pg_parse_and_plan into two routines. The old code would not, for
example, do the right thing with END; SELECT... submitted in one query
string when it had been in transaction abort state, because it'd decide
to skip planning the SELECT before it had executed the END. New
arrangement is simpler and doesn't force caller to plan if only
parse+rewrite is needed.
be an expression not just a simple Var, so long as only one table is
referenced (so that code isn't really any more difficult than before).
This whole thing is still fundamentally bogus, but at least we can accept
a few more cases than before.
WHERE in a place where it can be part of a nestloop inner indexqual.
As the code stood, it put the same physical sub-Plan node into both
indxqual and indxqualorig of the IndexScan plan node. That confused
later processing in the optimizer (which expected that tracing the
subPlan list would visit each subplan node exactly once), and would
probably have blown up in the executor if the planner hadn't choked first.
Fix by making the 'fixed' indexqual be a complete deep copy of the
original indexqual, rather than trying to share nodes below the topmost
operator node. This had further ramifications though, because we were
making the aforesaid list of sub-Plan nodes during SS_process_sublinks
which is run before construction of the 'fixed' indexqual, meaning that
the copy of the sub-Plan didn't show up in that list. Fix by rearranging
logic so that the sub-Plan list is built by the final set_plan_references
pass, not in SS_process_sublinks. This may sound like a mess, but it's
actually a good deal cleaner now than it was before, because we are no
longer dependent on the assumption that planning will never make a copy
of a sub-Plan node.
pg_internal.init file in-place, which meant that if another backend
started at about the same time, it might read the incomplete file.
init_irels tries to guard against that, but I have now seen a crash
due to reading bad data from a partly-written file. (This may indicate
a kernel bug on my platform? Not sure.) Anyway, clearly the safest
course is to write the new pg_internal.init file under a unique temporary
filename, and rename it into place only after it's all written.
In the event of an elog() while the mode was set to immediate write,
there was no way for it to be set back to the normal delayed write.
The mechanism was a waste of space and cycles anyway, since the only user
was varsup.c, which could perfectly well call FlushBuffer directly.
Now it does just that, and the notion of a write mode is gone.
single integers, and lists of names, without surrounding them with quotes.
Remove all tokens which are defined as operators from ColID and ColLabel
to avoid precedence confusion. Thanks to Tom Lane for catching this.
to next integer. Previously, if selectivity was small, we could compute
very tiny scan cost on the basis of estimating that only 0.001 tuple
would be fetched, which is silly. This naturally led to some rather
silly plans...
Move CREATE FUNCTION/WITH clause to end of statement to get around
shift/reduce conflicts with type names containing "WITH".
Add lots of tokens as allowed ColId's and/or ColLabel's,
so this should be a complete set for the v7.0 release.
keys lists of Constraint nodes. This eliminates a type pun that would
probably have caused trouble someday, and eliminates circular references
in the parsetree that were causing trouble now.
Also, change parser's uses of strcasecmp() to strcmp(). Since scan.l
has downcased any unquoted identifier, it is never correct to check an
identifier with strcasecmp() in the parser. For example,
CREATE TABLE FOO (f1 int, UNIQUE("F1"));
was accepted, which is wrong, and xlateSqlFunc did more than it should:
select datetime();
ERROR: Function 'timestamp()' does not exist
(good)
select "DateTime"();
ERROR: Function 'timestamp()' does not exist
(bad)
Clean up grotty coding in them, too. AFAICS from the CVS logs, these
have been broken since Postgres95, so I'm not going to insist on an
initdb to fix them now...
to avoid undue sensitivity to roundoff error, believe that a zero
or slightly negative range estimate should represent a small
positive selectivity, rather than falling back on a generic default
estimate.
use a default value that's fairly small. We were generating a result
of about 0.1, but I think 0.01 is probably better --- want to encourage
use of an indexscan in this situation.
costs using the inner path's parent->rows count as the number of tuples
processed per inner scan iteration. This is wrong when we are using an
inner indexscan with indexquals based on join clauses, because the rows
count in a Relation node reflects the selectivity of the restriction
clauses for that rel only. Upshot was that if join clause was very
selective, we'd drastically overestimate the true cost of the join.
Fix is to calculate correct output-rows estimate for an inner indexscan
when the IndexPath node is created and save it in the path node.
Change of path node doesn't require initdb, since path nodes don't
appear in saved rules.
to simplify constant expressions and expand SubLink nodes into SubPlans
is done in a separate routine subquery_planner() that calls union_planner().
We formerly did most of this work in query_planner(), but that's the
wrong place because it may never see the real targetlist. Splitting
union_planner into two routines also allows us to avoid redundant work
when union_planner is invoked recursively for UNION and inheritance
cases. Upshot is that it is now possible to do something like
select float8(count(*)) / (select count(*) from int4_tbl) from int4_tbl
group by f1;
which has never worked before.
Bruce Momjian
Tom Lane
Thomas G. Lockhart
Vadim B. Mikheev
Peter Eisentraut
Hiroshi Inoue