method to pass extra data to the consistent() and comparePartial() methods.
This is the core infrastructure needed to support the soon-to-appear
contrib/btree_gin module.  The APIs are still upward compatible with the
definitions used in 8.3 and before, although *not* with the previous 8.4devel
function definitions.

catversion bump for changes in pg_proc entries (although these are just
cosmetic, since GIN doesn't actually look at the function signature before
calling it...)

Teodor Sigaev and Oleg Bartunov

not global variables of anonymous enum types.  This didn't actually hurt
much because most linkers will just merge the duplicated definitions ...
but some will complain.  Per bug #4731 from Ceriel Jacobs.

Backpatch to 8.1 --- the declarations don't exist before that.

them from degrading badly when the input is sorted or nearly so.  In this
scenario the tree is unbalanced to the point of becoming a mere linked list,
so insertions become O(N^2).  The easiest and most safely back-patchable
solution is to stop growing the tree sooner, ie limit the growth of N.  We
might later consider a rebalancing tree algorithm, but it's not clear that
the benefit would be worth the cost and complexity.  Per report from Sergey
Burladyan and an earlier complaint from Heikki.

Back-patch to 8.2; older versions didn't have GIN indexes.

multiple index entries in a holding area before adding them to the main index
structure.  This helps because bulk insert is (usually) significantly faster
than retail insert for GIN.

This patch also removes GIN support for amgettuple-style index scans.  The
API defined for amgettuple is difficult to support with fastupdate, and
the previously committed partial-match feature didn't really work with
it either.  We might eventually figure a way to put back amgettuple
support, but it won't happen for 8.4.

catversion bumped because of change in GIN's pg_am entry, and because
the format of GIN indexes changed on-disk (there's a metapage now,
and possibly a pending list).

Teodor Sigaev

meant it had to be built on-the-fly at each entry to default_reloptions.

just enable/disable.

probes --- the BUFFER_READ_DONE probe provides the same information and more
besides.  Expand the LOCK_WAIT_START/DONE probe arguments so that there's
actually some chance of telling what is being waited for.  Update and
clean up the documentation.

DTrace probes, so that ordinary reads can be distinguished from relation
extension operations.  Move buffer_read_start probe to before the
smgrnblocks() call that's needed in the isExtend case, since really that step
should be charged as part of the time needed for the extension operation.
(This makes it slightly harder to match the read_start with the associated
read_done, since now you can't match them on blockNumber, but it should still
be possible since isExtend operations on the same relation can never be
interleaved.)  Per recent discussion.

In passing, add the page identity (forkNum/blockNum) to the parameters of the
buffer_flush_start/buffer_flush_done probes, which were unaccountably lacking
the info.

consistent, translate where intended, const-ify declarations.
Resolves a gripe from Alvaro as well as some stuff I didn't like.

is still available, but you must now write the long equivalent --inserts
or --column-inserts.  This change is made to eliminate confusion with the
use of -d to specify a database name in most other Postgres client programs.
Original patch by Greg Mullane, modified per subsequent discussion.

noise words for the last twelve years, for compatibility with Berkeley-era
output formatting of the special INVALID values for those datatypes.
Considering that the datatypes themselves have been deprecated for awhile,
this is taking backwards compatibility a little far.  Per gripe from Josh
Berkus.

distribution, by creating a special fast path for the (first few) most common
values of the outer relation.  Tuples having hashvalues matching the MCVs
are effectively forced to be in the first batch, so that we never write
them out to the batch temp files.

Bryce Cutt and Ramon Lawrence, with some editorialization by me.

are.  per discussion on hackers

reinstalling the default signal handler doesn't work as it is on Windows.
Presumably core dumps on SIGQUIT are not a problem on Windows, so rather
than figure out what header files or other changes are required to make it
work, just don't bother.

Per suggestion from Ron Mayer.

postmaster uses for immediate shutdown. Trap SIGUSR1 as the preferred
signal for that.

Per report by Fujii Masao and subsequent discussion on -hackers.

Makefile to use it.

big5/win950 <-> UTF8 conversion tables.

Per report by Roger Chang.

the cause of the "could not write to log file: Bad file descriptor"
errors reported at
http://archives.postgresql.org//pgsql-general/2008-06/msg00193.php

Backpatch to 8.3, the race condition was introduced by the CSV logging
patch.

Analysis and patch by Gurjeet Singh.

just '00'.

implemented.

data structure, rather than silently truncating them.  Andrew Gierth

to date, as per bug #4702 and subsequent discussion.  In particular, make it
work for years specified using AD/BC or CC fields, and fix the test for "no
year specified" so that it doesn't trigger inappropriately for 1 BC (which it
was doing even in code paths that had nothing to do with to_timestamp).  I
also did some minor code beautification in the non-ISO-day-number code path.

This area has been busted all along, but because the code has been rewritten
repeatedly, it would be considerable trouble to back-patch.  It's such a
corner case that it doesn't seem worth the effort.

previously repointed TABLE dependencies to TABLE DATA.  Mea culpa.

make it include the time for the possible smgropen() call, but that
results in a null pointer dereference :-(.

An alternative solution would be to fetch the buffer tag instead of
looking at *reln, but I'll just put it back as it was for the moment.

BTW, this indicates that DTrace probes evaluate their arguments even
when nominally inactive.  What was that about "zero cost", again?