initdb.  We should create all the standard dictionaries even though
some of them may not work in template1's encoding.  Per Teodor.

This prevents needing to do complex and poorly-defined updates of the
mapping table if the new parser has different token types than the old.
Per discussion.

syncing the existing docs with the final syntax decisions.

names in the former case seems more consistent with the behavior of
other \dF commands.

init options of the template as top-level options in the syntax.  This also
makes ALTER a bit easier to use, since options can be replaced individually.
I also made these statements verify that the tmplinit method will accept
the new settings before they get stored; in the original coding you didn't
find out about mistakes until the dictionary got invoked.

Under the hood, init methods now get options as a List of DefElem instead
of a raw text string --- that lets tsearch use existing options-pushing code
instead of duplicating functionality.

'with map' parameter; as things now stand there's really not much point
in specifying a config-to-copy if you don't copy its map.  Also, use
COPY instead of TEMPLATE as the key word for a config-to-copy, so as
to avoid confusion with text search templates.  Per discussion; the
just-committed reference page for the command already describes it
this way.

pages for the new SQL commands.  I also committed Bruce's text search
introductory chapter, as-is except for fixing some markup errors,
so that there would be a place for the reference pages to link to.

There's not much point in prettifying machine-generated code, and it
seems best to keep these files exactly like upstream anyway.  Also add
some notes about why various files are excluded.

Windows builds.  In passing, fix an obsolete comment, per gripe from
Greg Stark.

(Still needs to build the .sql output files, but this handles the C part
of the build)

on mingw and probably cygwin.

objects to it.

of int64 for int32.  Per reports from Merlin Moncure and Andrew Chernow.

of the datatype to int64.  Per Andrew Chernow.

byte after the last full byte of the bit array, regardless of whether that
byte was part of the valid data or not.  Found by buildfarm testing.
Thanks to Stefan Kaltenbrunner for nailing down the cause.

the core additions.  For the moment I diked it out of contrib/Makefile.
We should look at turning it into a backward-compatibility package.

Oleg Bartunov and Teodor Sigaev, but I did a lot of editorializing,
so anything that's broken is probably my fault.

Documentation is nonexistent as yet, but let's land the patch so we can
get some portability testing done.

database.

< * Allow server log information to be output as INSERT statements
> * -Allow server log information to be output as CSV format

redirect_stderr to logging_collector.
Original patch from Arul Shaji, subsequently modified by Greg Smith, and then
heavily modified by me.

>
> * Reduce XID consumption of read-only queries
>
>    http://archives.postgresql.org/pgsql-hackers/2007-08/msg00516.php
>

are not one of the query's defined result relations, but nonetheless have
triggers fired against them while the query is active.  This was formerly
impossible but can now occur because of my recent patch to fix the firing
order for RI triggers.  Caching a ResultRelInfo avoids duplicating work by
repeatedly opening and closing the same relation, and also allows EXPLAIN
ANALYZE to "see" and report on these extra triggers.  Use the same mechanism
to cache open relations when firing deferred triggers at transaction shutdown;
this replaces the former one-element-cache strategy used in that case, and
should improve performance a bit when there are deferred triggers on a number
of relations.

row within one query: we were firing check triggers before all the updates
were done, leading to bogus failures.  Fix by making the triggers queued by
an RI update go at the end of the outer query's trigger event list, thereby
effectively making the processing "breadth-first".  This was indeed how it
worked pre-8.0, so the bug does not occur in the 7.x branches.
Per report from Pavel Stehule.

>   A third idea would be for a heap scan to check if all rows are visible
>   and if so set a per-table flag which can be checked by index scans.
>   Any change to the table would have to clear the flag.  To detect
>   changes during the heap scan a counter could be set at the start and
>   checked at the end --- if it is the same, the table has not been
>   modified --- any table change would increment the counter.

that still thought they could set HEAP_XMAX_COMMITTED immediately after
seeing the other transaction commit.  Make them use the same logic as
tqual.c does to determine if the hint bit can be set yet.

< 	o Use backend PREPARE/EXECUTE facility for ecpg where possible