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 ...

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

a non-leading % would be put into the >=/<= patterns.  Also, repair
longstanding confusion about whether %% means a literal %%.  The SQL92
doesn't say any such thing, and textlike() knows that, but gram.y didn't.

index, etc is too long, truncate until it fits.

few percent speedup in INSERT...

GROUP BY or ORDER BY expressions in INSERT ... SELECT.

aggregate functions, as in
	select a, b from foo group by a;
The ungrouped reference to b is not kosher, but formerly we neglected to
check this unless there was an aggregate function somewhere in the query.

SelectStmt and CursorStmt tried to parse FOR UPDATE ... / FOR READ ONLY.
Cursor now checks that it is read only by looking at forUpdate of Query.
SelectStmt handles FOR READ ONLY too.

Jan

will pass through rather than spitting up.  This is necessary to handle
cases where coerce_type causes a subexpression to be retransformed, as in
	SELECT count(*) + 1.0 FROM table

for SERIAL column's constraint, but forgot to increase space palloc'd...

 SERIAL data type DEFAULT clause.
This fixes a problem finding the sequence name when mixed case table names
 are involved.

 compiler warnings about an unused variable.

lists are now plain old garden-variety Lists, allocated with palloc,
rather than specialized expansible-array data allocated with malloc.
This substantially simplifies their handling and eliminates several
sources of memory leakage.
Several basic types of erroneous queries (syntax error, attempt to
insert a duplicate key into a unique index) now demonstrably leak
zero bytes per query.

in Resdom and GroupClause so changing of resno's doesn't confuse
the grouping any more.

Jan

 and lock syntax as fully parsed tokens.
Two keywords for isolation are non-reserved SQL92
 (COMMITTED, SERIALIZABLE).
All other new keywords are non-reserved Postgres (not SQL92)
 (ACCESS, EXCLUSIVE, MODE, SHARE).
Add syntax to allow CREATE [GLOBAL|LOCAL] TEMPORARY TABLE, throwing an
 error if GLOBAL is specified.

 constraints. Reported by Tom Lane.
Now, check for duplicate indices and retain the one which is a primary-key.
Adjust elog NOTICE messages to surround table and column names with single
 quotes.

 the obvious conversion.
Define a new pattern "decimal" which is non-exponential floating point
 for use with numeric() and decimal() types.

real affect now.

been applied. The patches are in the .tar.gz attachment at the end:

varchar-array.patch     this patch adds support for arrays of bpchar() and
                        varchar(), which where always missing from postgres.

                        These datatypes can be used to replace the _char4,
                        _char8, etc., which were dropped some time ago.

block-size.patch        this patch fixes many errors in the parser and other
                        program which happen with very large query statements
                        (> 8K) when using a page size larger than 8192.

                        This patch is needed if you want to submit queries
                        larger than 8K. Postgres supports tuples up to 32K
                        but you can't insert them because you can't submit
                        queries larger than 8K. My patch fixes this problem.

                        The patch also replaces all the occurrences of `8192'
                        and `1<<13' in the sources with the proper constants
                        defined in include files. You should now never find
                        8192 hardwired in C code, just to make code clearer.


--
Massimo Dal Zotto

that, but it'd be a New Feature, wouldn't it ... in the meantime,
avoiding a backend crash seems worthwhile.

Things are better now.