Original code used float8out(), but the resulting exponential notation
 was not handled (e.g. '3E9' was decoded as '3').

Should this be in the tutorial instead?

Document date/time input parsing procedure.

Probably not acceptable yet. Need to check some math symbols and markup.

nodes with HAVING qualifier of upper plan.  Have not seen any failures,
just being a little bit paranoid...

gcc quite so unhappy.

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

from EXCEPT/HAVING patch.  Cases involving nontrivial GROUP BY expressions
now work again.  Also, the code is at least somewhat better documented...

the cost of reading the source data.

to save a little bit of backend startup time.  This way, the first
backend started after a VACUUM will rebuild the init file with up-to-date
statistics for the critical system indexes.

an identifier :-(.  Sloppy transmission of a patch, likely.

FATAL 1:btree: BTP_CHAIN flag was expected

should be faster.

This makes no difference to the optimizer, which has already decided what
it's gonna do, but it makes the output of EXPLAIN much more plausible.

sometimes estimating an index scan of a table to be cheaper than a
sequential scan of the same tuples...

from ever returning a path.  This put a bit of a crimp in the system's
ability to generate intelligent merge-join plans...

before going into queue behind person with higher piority.

Jan

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

Things are better now.

due to lack of check for recursing into a null subexpression.

this is not revealed by any of our regression tests...

Jan

These are no longer used ...

provides string to be used for expected/* files for system specific output...

the database encoding and the client encoding match the encoding expected
by the test.  So, force both of them to be set from the MULTIBYTE
environment var.  This allows regress tests to be run successfully in
multibyte environments other than the compiled-in default.