Add prosecdef to \df+ output.

Jon Erdman, reviewed by Phil Sorber and Stephen Frost.
docs:  In ecpg, clarify how username/password colon parameters are used

Backpatch to 9.2.

Patch from Alan B
Make it easy to time out pg_isready, and make the default 3 seconds.

Along the way, add a missing line to the help message.

Phil Sorber, reviewed by Fujii Masao
doc:  split search_path index entries into separate secondaries

Karl O. Pinc
doc:  adjust search_path secondary index mention

per Tom Lane
doc:  merge ecpg username/password example into C comment

Backpatch to 9.2

per Tom Lane
Change plan caching to honor, not resist, changes in search_path.

In the initial implementation of plan caching, we saved the active
search_path when a plan was first cached, then reinstalled that path
anytime we needed to reparse or replan.  The idea of that was to try to
reselect the same referenced objects, in somewhat the same way that views
continue to refer to the same objects in the face of schema or name
changes.  Of course, that analogy doesn't bear close inspection, since
holding the search_path fixed doesn't cope with object drops or renames.
Moreover sticking with the old path seems to create more surprises than
it avoids.  So instead of doing that, consider that the cached plan depends
on search_path, and force reparse/replan if the active search_path is
different than it was when we last saved the plan.

This gets us fairly close to having "transparency" of plan caching, in the
sense that the cached statement acts the same as if you'd just resubmitted
the original query text for another execution.  There are still some corner
cases where this fails though: a new object added in the search path
schema(s) might capture a reference in the query text, but we'd not realize
that and force a reparse.  We might try to fix that in the future, but for
the moment it looks too expensive and complicated.
doc: mention commit_delay is only honored if fsync is enabled

per Tianyin Xu
Fix plpython's handling of functions used as triggers on multiple tables.

plpython tried to use a single cache entry for a trigger function, but it
needs a separate cache entry for each table the trigger is applied to,
because there is table-dependent data in there.  This was done correctly
before 9.1, but commit 46211da1b84bc3537e799ee1126098e71c2428e8 broke it
by simplifying the lookup key from "function OID and triggered table OID"
to "function OID and is-trigger boolean".  Go back to using both OIDs
as the lookup key.  Per bug report from Sandro Santilli.

Andres Freund
doc:  revert 80c20fcf3df17309b3c131962045825f42e45bc7 and
0e93959a70ac6e7c7858d1d6fb00645e7540a1cc

Revert patch that modified doc index mentions of search_path

Per Peter E.
merge pg_database.h
Allow CREATE TABLE IF EXIST so succeed if the schema is nonexistent

Previously, CREATE TABLE IF EXIST threw an error if the schema was
nonexistent.  This was done by passing 'missing_ok' to the function that
looks up the schema oid.
Issue ERROR if FREEZE mode can't be honored by COPY

Previously non-honored FREEZE mode was ignored.  This also issues an
appropriate error message based on the cause of the failure, per
suggestion from Tom.  Additional regression test case added.
Update LookupExplicitNamespace() comments;  commit message update

Also, commit 7e2322dff30c04d90c0602d2b5ae24b4881db88b affected DROP
TABLE IF EXISTS, not CREATE TABLE IF EXISTS.
Update comments in new DROP IF EXISTS code; commit message update

DROP IF EXISTS with a missing schema in commit
7e2322dff30c04d90c0602d2b5ae24b4881db88b applies not only to tables, but
to DROP IF EXISTS with missing schemas for indexes, views, sequences,
and foreign tables.  Yeah!
Make LATERAL implicit for functions in FROM.

The SQL standard does not have general functions-in-FROM, but it does
allow UNNEST() there (see the <collection derived table> production),
and the semantics of that are defined to include lateral references.
So spec compliance requires allowing lateral references within UNNEST()
even without an explicit LATERAL keyword.  Rather than making UNNEST()
a special case, it seems best to extend this flexibility to any
function-in-FROM.  We'll still allow LATERAL to be written explicitly
for clarity's sake, but it's now a noise word in this context.

In theory this change could result in a change in behavior of existing
queries, by allowing what had been an outer reference in a function-in-FROM
to be captured by an earlier FROM-item at the same level.  However, all
pre-9.3 PG releases have a bug that causes them to match variable
references to earlier FROM-items in preference to outer references (and
then throw an error).  So no previously-working query could contain the
type of ambiguity that would risk a change of behavior.

Per a suggestion from Andrew Gierth, though I didn't use his patch.
Made ecpglib use translated messages.

Bug reported and fixed by Chen Huajun <chenhj@cn.fujitsu.com>.
Handle SPIErrors raised directly in PL/Python code.

If a PL/Python function raises an SPIError (or one if its subclasses)
directly with python's raise statement, treat it the same as an SPIError
generated internally. In particular, if the user sets the sqlstate
attribute, preserve that.

Oskari Saarenmaa and Jan Urbański, reviewed by Karl O. Pinc.
DROP OWNED: don't try to drop tablespaces/databases

My "fix" for bugs #7578 and #6116 on DROP OWNED at fe3b5eb08a1 not only
misstated that it applied to REASSIGN OWNED (which it did not affect),
but it also failed to fix the problems fully, because I didn't test the
case of owned shared objects.  Thus I created a new bug, reported by
Thomas Kellerer as #7748, which would cause DROP OWNED to fail with a
not-for-user-consumption error message.  The code would attempt to drop
the database, which not only fails to work because the underlying code
does not support that, but is a pretty dangerous and undesirable thing
to be doing as well.

This patch fixes that bug by having DROP OWNED only attempt to process
shared objects when grants on them are found, ignoring ownership.

Backpatch to 8.3, which is as far as the previous bug was backpatched.
REASSIGN OWNED: handle shared objects, too

Give away ownership of shared objects (databases, tablespaces) along
with local objects, per original code intention.  Try to make the
documentation clearer, too.

Per discussion about DROP OWNED's brokenness, in bug #7748.

This is not backpatched because it'd require some refactoring of the
ALTER/SET OWNER code for databases and tablespaces.