to index_selectivity so that it can be handed an indexqual clause list
rather than a bunch of assorted derivative data.

The only place it was being used was as temporary storage in indxpath.c,
and the logic was wrong: the same restrictinfo node could get chosen to
carry the info for two different joins.  Right fix is to return a second
list of unjoined-relids parallel to the list of clause groups.

identified by Hiroshi (incorrect cost attributed to OR clauses
after multiple passes through set_rest_selec()).  I think the code
was trying to allow selectivities of OR subclauses to be passed in
from outside, but noplace was actually passing any useful data, and
set_rest_selec() was passing wrong data.

Restructure representation of "indexqual" in IndexPath nodes so that
it is the same as for indxqual in completed IndexScan nodes: namely,
a toplevel list with an entry for each pass of the index scan, having
sublists that are implicitly-ANDed index qual conditions for that pass.
You don't want to know what the old representation was :-(

Improve documentation of OR-clause indexscan functions.

Remove useless 'notclause' field from RestrictInfo nodes.  (This might
force an initdb for anyone who has stored rules containing RestrictInfos,
but I do not think that RestrictInfo ever appears in completed plans.)

comments.  This file was full of obsolete and just plain wrong
commentary...

invoked during exit from a standalone backend, leading to core dump.
This is the cause of the recently reported initdb-time crash :-(.
Sorry folks...

lisp.sgml is a placeholder for Eric Marsden's upcoming contribution.
catalogs.sgml is not yet marked up or integrated.
 It should perhaps become an appendix.

ecpg reference page still needs formatting.

unexpected loss of connection to frontend.

the query string to handle any length, I discovered that under certain
conditions, psql will core dump when handling long strings.  Thus, the
patch.  It was caused by a buffer overrun, probably not noticeable in a lot
of cases, but pretty noticeable in mine.

Problem was caused by the fact that the length check is only performed after
the check for a ; to get the end of the query and execute.

Cheers...

MikeA

support, but which the grammar was accepting.  Also, fix several bugs
having to do with failure to copy fields up from a subselect to a select
or insert node.

Massimo

approproate.

SELECT a/2, a/2 FROM test_missing_target GROUP BY a/2;
to be ambiguous ... which I think is correct behavior.

of the SELECT part of the statement is just like a plain SELECT.  All
INSERT-specific processing happens after the SELECT parsing is done.
This eliminates many problems, e.g. INSERT ... SELECT ... GROUP BY using
the wrong column labels.  Ensure that DEFAULT clauses are coerced to
the target column type, whether or not stored clause produces the right
type.  Substantial cleanup of parser's array support.