with expression_tree_walker-based code.  The former failed to cope with
expressions containing SubLinks, and the latter returned TRUE for both
SubLinks and Aggrefs (cut-and-paste bug?).  There is a lot more scope for
using expression_tree_walker in this module, but I'll restrain myself
until the 6.6 split occurs from touching not-demonstrably-broken code.

sure if they are all fixed, because rewriter is now the stumbling block,
but at least some cases work that did not work before.

SubLink nodes after all ...

 aclchk.c: heap_close() is not called after calling heap_openr().

Atsushi Ogawa

is parse_aggs.c.  This fixes its failure to cope with (at least) CaseExpr
and ArrayRef nodes, which is the reason why both of these fail in 6.5:
select coalesce(f1,0) from int4_tbl group by f1;
ERROR:  Illegal use of aggregates or non-group column in target list
select sentence.words[0] from sentence group by sentence.words[0];
ERROR:  Illegal use of aggregates or non-group column in target list
The array case still fails, but at least it's not parse_agg's fault
anymore ... considering that we now support CASE officially, I think
it's important to fix the first example ...

will gradually replace all of the boilerplate tree-walk-recursion code that
currently exists in O(N) slightly different forms in N subroutines.
I've had it with adding missing cases to these subroutines...

functions, in order to work around oversight in 6.5 release: rtree
index functions haven't got any.  Mea culpa ...

Did not check the function declarations as carefully as the other parts,
 though all of the function names *do* match up with D&D.

manipulate rtable the same way executor does).

used to overrun its fixed-size arrays before detecting error; not cool).
Also, replace uses of magic constant '8' with 'MAXFARGS'.

for Irix.

 August 1994 draft standard.
Use the ecpg support libraries to write the CLI interface?
Date and Darwen claim that CLI is a more modern and flexible approach...

type name.

Came out with max 79 columns from Applix by defining the page width at
 10 inches and the right margin at 9.5 inches, then exporting
 as "ASCII Layout".

 Left them out after splitting them
 from the CREATE TABLE and SELECT sources.

Split reference pages for CREATE TABLE AS and SELECT INTO to allow psgml
 (the emacs parser) to handle parsing.

#if defined(__mc68000__) && defined(__linux__)
so that other m68k systems(such as NetBSD) will not be affected.

to DEF_NBUFFERS for readability.  Make sure the default value is OK
according to postmaster.c's new sanity check for -B values.

special hack to ensure it would close its output file even after failure
due to elog(ERROR) partway through the copy.  This is now unnecessary
because fd.c takes care of cleaning up open files at transaction abort;
worse, after fd.c closed the file copy.c would try to do so *again* at
the start of the next COPY command.  This would result in havoc in most
implementations of stdio library.

tlist and qual are NULL.  It ought to handle these the same as the cases
where tlist contains only constant expressions, ie, be willing to generate
a Result-node plan.  This did not use to matter, but it does now because
union_planner will flatten the tlist when aggregates are present.  Thus,
'select count(1) from table' now causes query_planner to be given a null
tlist, and to duplicate 6.4's behavior we need it to give back a Result
plan rather than refusing the query.  6.4 was arguably doing the Wrong
Thing for this query, but I'm not going to open a semantics issue right
before 6.5 release ... can revisit that problem later.

returned NULL, which it will do in some cases where an elog(ERROR) would
probably be more appropriate.  For the moment, generate a not-very-
informative error message rather than proceeding to certain coredump.
Probably ought to think about making query_planner elog instead of
returning NULL, but this is at least a safe change for now.

pointer to palloc'd but uninitialized memory.  This is not cool; anyone looking
at the returned 'tuple' would at best coredump and at worst behave in a
bizarre and irreproducible way.  Fix it to return a predictable value,
namely a correctly-set-up palloc'd tuple containing zero attributes.
I believe this fix is both safe and critical.