up relations, but rather order old/new relations and use the same array
index value for both.  This should speed up pg_upgrade for databases
with many relations.

that we restore by oid;  they can be handled like regular tables when
creating the file mapping structure.

Josh Kupershmidt

The underlying C code still needs work, but this at least gets its
current regression test passing again.

in pg_largeobject_metadata).

because the old and new values are identical.

which is stored in pg_largeobject_metadata.

No backpatch to 9.0 because you can't migrate from 9.0 to 9.0 with the
same catversion (because of tablespace conflict), and a pre-9.0
migration to 9.0 has not large object permissions to migrate.

Toast tables have identical pg_class.oid and pg_class.relfilenode, but
for clarity it is good to preserve the pg_class.oid.

Update comments regarding what is preserved, and do some
variable/function renaming for clarity.

Add more "internal" arguments so that these pg_proc entries reflect the
current preferred API.  This is purely a cosmetic change, since GIN doesn't
actually consult the pg_proc entry when calling a support function.
Accordingly, no catversion bump.

Per my recent proposal(s).  Null key datums can now be returned by
extractValue and extractQuery functions, and will be stored in the index.
Also, placeholder entries are made for indexable items that are NULL or
contain no keys according to extractValue.  This means that the index is
now always complete, having at least one entry for every indexed heap TID,
and so we can get rid of the prohibition on full-index scans.  A full-index
scan is implemented much the same way as partial-match scans were already:
we build a bitmap representing all the TIDs found in the index, and then
drive the results off that.

Also, introduce a concept of a "search mode" that can be requested by
extractQuery when the operator requires matching to empty items (this is
just as cheap as matching to a single key) or requires a full index scan
(which is not so cheap, but it sure beats failing or giving wrong answers).
The behavior remains backward compatible for opclasses that don't return
any null keys or request a non-default search mode.

Using these features, we can now make the GIN index opclass for anyarray
behave in a way that matches the actual anyarray operators for &&, <@, @>,
and = ... which it failed to do before in assorted corner cases.

This commit fixes the core GIN code and ginarrayprocs.c, updates the
documentation, and adds some simple regression test cases for the new
behaviors using the array operators.  The tsearch and contrib GIN opclass
support functions still need to be looked over and probably fixed.

Another thing I intend to fix separately is that this is pretty inefficient
for cases where more than one scan condition needs a full-index search:
we'll run duplicate GinScanEntrys, each one of which builds a large bitmap.
There is some existing logic to merge duplicate GinScanEntrys but it needs
refactoring to make it work for entries belonging to different scan keys.

Note that most of gin.h has been split out into a new file gin_private.h,
so that gin.h doesn't export anything that's not supposed to be used by GIN
opclasses or the rest of the backend.  I did quite a bit of other code
beautification work as well, mostly fixing comments and choosing more
appropriate names for things.

Itagaki Takahiro, edited by me.

Jehan-Guillaume de Rorthais, with some additional wordsmithing by me.

Itagaki Takahiro and Simon Riggs.

functions.

The previous example didn't make it clear whether array_upper returned
the last element or the index of the last element.

lo_insert.

handling.  (metadata user ids still an open issue).

up pg_dump's calling of pg_upgrade_support functions.

This can be overriden by using NOREPLICATION on the CREATE ROLE
statement, but by default they will have it, making it backwards
compatible and "less surprising" (given that superusers normally
override all checks).

servers because, like pg_largeobject, it is a system table whose
contents are not dumped by pg_dump --schema-only.

Missing support for VALID UNTIL in CREATE ROLE is also added.

In the previous coding, the parser emitted a List containing a C string,
which is no good, because copyObject() can't handle it.

Dimitri Fontaine

Add the view pg_stat_database_conflicts and a column to pg_stat_database,
and the underlying functions to provide the information.

Noted by Peter E.

Forgot this with previuos commit, line it up so it's easier to
submit (readable) patches against the MSVC build system.

Add new function pg_sequence_parameters that returns a sequence's start,
minimum, maximum, increment, and cycle values, and use that in the view.
(bug #5662; design suggestion by Tom Lane)

Also slightly adjust the view's column order and permissions after review of
SQL standard.