In this case extractQuery should returns -1 as nentries. This changes
prototype of extractQuery method to use int32* instead of uint32* for
nentries argument.
Based on that gincostestimate may see two corner cases: nothing will be found
or seqscan should be used.

Per proposal at http://archives.postgresql.org/pgsql-hackers/2007-01/msg01581.php

PS tsearch_core patch should be sightly modified to support changes, but I'm
waiting a verdict about reviewing of tsearch_core patch.

      o Fix RENAME to work on variables other than OLD/NEW
>
> 		  http://archives.postgresql.org/pgsql-hackers/2002-03/msg00591.php
>

>
> * Add REINDEX CONCURRENTLY, like CREATE INDEX CONCURRENTLY
>
>   This is difficult because you must upgrade to an exclusive table lock
>   to replace the existing index file.  CREATE INDEX CONCURRENTLY does not
>   have this complication.  This would allow index compaction without
>   downtime.

<   reindex rather than update the index.
>   reindex rather than update the index.  Also, index updates can
>   bloat the index.

> 	o ARRAY[[1,2],[3,4]])[1] should return the same values as
> 	  ARRAY[[1,2],[3,4]])[1:1];
>

more, and standard_conforming_strings less, because in the future non-E
strings will not treat backslashes specially.

Also use E'' strings where backslashes are used in examples. (The
existing examples would have drawn warnings.)

Backpatch to 8.2.X.

The original coding failed (tried to access deallocated memory) if there were
two active call sites (fn_extra pointers) for the same function and the
function definition was updated.  Also, if an update of a recursive function
was detected upon nested entry to the function, the existing compiled version
was summarily deallocated, resulting in crash upon return to the outer
instance.  Problem observed while studying a bug report from Sergiy
Vyshnevetskiy.

Bug does not exist before 8.1 since older versions just leaked the memory of
obsoleted compiled functions, rather than trying to reclaim it.

by plpgsql can themselves use SPI --- possibly indirectly, as in the case
of domain_in() invoking plpgsql functions in a domain check constraint.
Per bug #2945 from Sergiy Vyshnevetskiy.

Somewhat arbitrarily, I've chosen to back-patch this as far as 8.0.  Given
the lack of prior complaints, it doesn't seem critical for 7.x.

Hashing for aggregation purposes still needs work, so it's not time to
mark any cross-type operators as hashable for general use, but these cases
work if the operators are so marked by hand in the system catalogs.

actually used for anything.

< * Add Globally/Universally Unique Identifier (GUID/UUID)
> * -Add Globally/Universally Unique Identifier (GUID/UUID)

from exec.c and postmaster.c.

match because they contain a null join key (and the join operator is
known strict).  Improves performance significantly when the inner
relation contains a lot of nulls, as per bug #2930.

handy to prevent core dump files from disappearing, but it's useless now
because (a) we don't drop core in individual DB subdirectories anymore,
and (b) CREATE DATABASE forces an internal checkpoint anyway.

definitions of uuid_t that may be provided by the system headers. This
should hopefully fix the Win32 build problems reported by Magnus.

rel->tuples as well as rel->rows, since some estimation functions expect both
to be valid in every baserel.  Per report from Dave Dutcher.

reports; inspired by the misleading CONTEXT lines shown in recent bug report
from Stefan Kaltenbrunner.  Also, allow statement-type names shown in these
messages to be translated.

that defined in RFC 4122. This patch includes the basic implementation,
plus regression tests. Documentation and perhaps some additional
functionality will come later. Catversion bumped.

Patch from Gevik Babakhani; review from Peter, Tom, and myself.

safely in the presence of subtransactions.  To ensure that any ExprContext
shutdown callbacks are called at the right times, we have to have a separate
EState for each level of subtransaction.  Per "TupleDesc reference leak" bug
report from Stefan Kaltenbrunner.

Although I'm convinced the code is wrong as far back as 8.0, it doesn't seem
that there are any ways for the problem to really manifest before 8.2: AFAICS,
8.0 and 8.1 only use the ExprContextCallback mechanism to handle set-returning
functions, which cannot usefully be executed in a "simple expression" anyway.
Hence, no backpatch before 8.2 --- the risk of unforeseen breakage seems
to outweigh the chance of fixing something.

sprintf pushup to be sure we can report something useful for out-of-range
exitstatus?

formatted error messages.

create our own.

activity quiesce.  Possibly this will fix the large increase in
non-reproducible stats test failures we've noted since turning on
stats_row_level by default.

kept on par with that of scalararraysel(), else estimates that should
track might not.  Hence teach it about binary-compatible cases, too.

versus varchar[].  This oversight probably explains Ryan Holmes' recent
complaint --- he was getting a generic selectivity estimate instead of
anything intelligent.

than just numbers.

is now a target, no longer a modifier).

exactly at the point where we need to insert a new item, the calculation used
the wrong size for the "high key" of the new left page.  This could lead to
choosing an unworkable split, resulting in "PANIC: failed to add item to the
left sibling" (or "right sibling") failure.  Although this bug has been there
a long time, it's very difficult to trigger a failure before 8.2, since there
was generally a lot of free space on both sides of a chosen split.  In 8.2,
where the user-selected fill factor determines how much free space the code
tries to leave, an unworkable split is much more likely.  Report by Joe
Conway, diagnosis and fix by Heikki Linnakangas.