Convert a perl array to a postgres array when returned by Set Returning Functions as well as non SRFs. Backpatch to 8.1 where these facilities were introduced. with a little help from Abhijit Menon-Sen.

Zoltan Boszormenyi <zb@cybertec.at>.

TupleTableSlot nodes.  This eliminates the need to count in advance
how many Slots will be needed, which seems more than worth the small
increase in the amount of palloc traffic during executor startup.

The ExecCountSlots infrastructure is now all dead code, but I'll remove it
in a separate commit for clarity.

Per a comment from Robert Haas.

error message, rather than blundering on and failing with something opaque.

Sam Mason

Marko Kreen, Tom Lane

spacing tweaks so it produces exactly the same output as genbki.sh.

the strings seen during the bootstrap run.  There might have been some
actual point to doing that, many years ago, but as far as I can see the only
value now is to conserve a bit of memory.  Even if we cared about wasting
a megabyte or so during the initdb run, it'd be far more effective to
arrange to release memory at the end of each BKI command, instead of
intentionally hanging onto strings that might never be used again.
Not maintaining the table probably makes it faster too; but the main point
of this patch is to get rid of a couple hundred lines of unnecessary and
rather crufty code.

don't have gensub().  Use sub() instead, tedious though it be.

relation rowtype OID into the relcache entries it builds.  This ensures
that catcache copies of the relation tupdescs will be fully correct.
While the deficiency doesn't seem to have any effect in the current
sources, we have been bitten by not-quite-right catcache tupdescs before,
so it seems like a good idea to maintain the rule that they should be right.

hand-assigned rowtype OIDs, even when they are not "bootstrapped" catalogs
that have handmade type rows in pg_type.h.  Give pg_database such an OID.
Restore the availability of C macros for the rowtype OIDs of the bootstrapped
catalogs.  (These macros are now in the individual catalogs' .h files,
though, not in pg_type.h.)

This commit doesn't do anything especially useful by itself, but it's
necessary infrastructure for reverting some ill-considered changes in
relcache.c.

possibility of shared-inval messages causing a relcache flush while it tries
to fill in missing data in preloaded relcache entries.  There are actually
two distinct failure modes here:

1. The flush could delete the next-to-be-processed cache entry, causing
the subsequent hash_seq_search calls to go off into the weeds.  This is
the problem reported by Michael Brown, and I believe it also accounts
for bug #5074.  The simplest fix is to restart the hashtable scan after
we've read any new data from the catalogs.  It appears that pre-8.4
branches have not suffered from this failure, because by chance there were
no other catalogs sharing the same hash chains with the catalogs that
RelationCacheInitializePhase2 had work to do for.  However that's obviously
pretty fragile, and it seems possible that derivative versions with
additional system catalogs might be vulnerable, so I'm back-patching this
part of the fix anyway.

2. The flush could delete the *current* cache entry, in which case the
pointer to the newly-loaded data would end up being stored into an
already-deleted Relation struct.  As long as it was still deleted, the only
consequence would be some leaked space in CacheMemoryContext.  But it seems
possible that the Relation struct could already have been recycled, in
which case this represents a hard-to-reproduce clobber of cached data
structures, with unforeseeable consequences.  The fix here is to pin the
entry while we work on it.

In passing, also change RelationCacheInitializePhase2 to Assert that
formrdesc() set up the relation's cached TupleDesc (rd_att) with the
correct type OID and hasoids values.  This is more appropriate than
silently updating the values, because the original tupdesc might already
have been copied into the catcache.  However this part of the patch is
not in HEAD because it fails due to some questionable recent changes in
formrdesc :-(.  That will be cleaned up in a subsequent patch.

Author: Marko Kreen <markokr@gmail.com>

to create a function for it.

Procedural languages now have an additional entry point, namely a function
to execute an inline code block.  This seemed a better design than trying
to hide the transient-ness of the code from the PL.  As of this patch, only
plpgsql has an inline handler, but probably people will soon write handlers
for the other standard PLs.

In passing, remove the long-dead LANCOMPILER option of CREATE LANGUAGE.

Petr Jelinek

Introduced in 8.4 rewrite of dependency.c.
Per bug #5072 from Amit Khandekar.

This is mainly to make the functionality consistent with the proposed \u
escape syntax.

Prevent creation of 16GB files during fsync testing; only create 16MB
files;  backpatch to 8.4.X.

This is intentionally similar to the recently revised syntax for EXPLAIN
options, ie, (name value, ...).  The old syntax is still supported for
backwards compatibility, but we intend that any options added in future
will be provided only in the new syntax.

Robert Haas, Emmanuel Cecchet

preinitialized local variables, this does not affect the function's semantics
as seen by callers; allowing assignment simply avoids the need to create more
local variables in some cases.  In any case we were being rather inconsistent
since only scalar parameters were getting marked constant.

No documentation change, since parameters were never documented as being
marked constant anyway.

Steve Prentice

trying to parse COPY options exactly in psql's \copy support.  Instead,
just send the options as-is and let the backend sort it out.

Emmanuel Cecchet

tests into a small common subroutine, and eliminate an unnecessary difference
in the order in which conditions are tested.  Per a comment from Robert Haas.

only for secondary page split (i.e. for non-first columns of index)

 Patch by Paul Ramsey <pramsey@opengeo.org>

function that returns the current transaction status.

Instead of requiring translators to translate the entire SQL command
synopses, change create_help.pl to only require them to translate the
placeholders, and paste those into the synopsis using a printf mechanism.
Make some small updates to the markup to make it easier to parse.

Note: This causes msgmerge of gettext 0.17 to segfault.  You will need
the patch from https://savannah.gnu.org/bugs/?27474 to make it work.
msgmerge usually only runs on babel.postgresql.org, however.

Update docs to clearly explain NULL value matching behavior, per Andrew.

Backpatch to 8.4.X.

ignored because it can only be set at server start.  In particular,
hiding the main reason in the detail message was suboptimal.

Clearify documentation of CVS's output of NULL values, per suggestion
from Magnus.

Backpatch to 8.4.X.

is unique and is not referenced above the join.  In this case the inner
side doesn't affect the query result and can be thrown away entirely.
Although perhaps nobody would ever write such a thing by hand, it's
a reasonably common case in machine-generated SQL.

The current implementation only recognizes the case where the inner side
is a simple relation with a unique index matching the query conditions.
This is enough for the use-cases that have been shown so far, but we
might want to try to handle other cases later.

Robert Haas, somewhat rewritten by Tom

Author: Alexey Klyukin <alexk@commandprompt.com>

In practice these mistakes were always masked when full_page_writes was on,
because XLogInsert would always choose to log the full page, and then
ginRedoInsertListPage wouldn't try to do anything.  But with full_page_writes
off a WAL replay failure was certain.

The GIN_INSERT_LISTPAGE record type could probably be eliminated entirely
in favor of using XLOG_HEAP_NEWPAGE, but I refrained from doing that now
since it would have required a significantly more invasive patch.

In passing do a little bit of code cleanup, including making the accounting
for free space on GIN list pages more precise.  (This wasn't a bug as the
errors were always in the conservative direction.)

Per report from Simon.  Back-patch to 8.4 which contains the identical code.