regession test output, and update pgindent script to avoid them in the
future.

marked stable.

We had originally made the stronger assumption that NOT A refutes any B
if B implies A, but this fails in three-valued logic, because we need to
prove B is false not just that it's not true.  However the logic does
go through if B is equal to A.

Recognizing this limited case is enough to handle examples that arise when
we have simplified "bool_var = true" or "bool_var = false" to just "bool_var"
or "NOT bool_var".  If we had not done that simplification then the
btree-operator proof logic would have been able to prove that the expressions
were contradictory, but only for identical expressions being compared to the
constants; so handling identical A and B covers all the same cases.

The motivation for doing this is to avoid unexpected asymmetrical behavior
when a partitioned table uses a boolean partitioning column, as in today's
gripe from Dominik Sander.

Back-patch to 8.2, which is as far back as predicate_refuted_by attempts to
do anything at all with NOTs.

per SQL standard, and mention 7.3 behavior at the end.

how often we do SSL session key renegotiation. Can be set to
0 to disable renegotiation completely, which is required if
a broken SSL library is used (broken patches to CVE-2009-3555
a known cause) or when using a client library that can't do
renegotiation.

format as in PQconnectdb(). As pointed out by Thom Brown.

it's asynchronous.

Per complaint from Greg Stark.

Per discussion.

error cases less intimidating for novices.  Per discussion.

Greg Smith

The main motivation for changing this is bug #4921, in which it's pointed out
that it's no longer safe to apply ltree operations to the result of
ARRAY(SELECT ...) if the sub-select might return no rows.  Before 8.3,
the ARRAY() construct would return NULL, which might or might not be helpful
but at least it wouldn't result in an error.  Now it returns an empty array
which results in a failure for no good reason, since the ltree operations
are all perfectly capable of dealing with zero-element arrays.

As far as I can find, these ltree functions are the only places where zero
array dimensionality is rejected unnecessarily.

Back-patch to 8.3 to prevent behavioral regression of queries that worked
in older releases.

supported release.

a desirable fashion in archive-dump cases, ie you should get the pg_dump
version not the pg_restore version.

This was evidently broken by the CREATE TABLE OF TYPE patch.  It would have
been noticed if anyone had bothered to try dumping and restoring the
regression database ...

significantly uglier kluges that were working around the change in plpgsql's
preinstalled status.

will work whether or not the specified language is preinstalled.  This
responds to some complaints about having to change test scripts because
plpgsql is preinstalled as of 9.0.

This operates in the same way as other CREATE OR REPLACE commands, ie,
it replaces everything but the ownership and ACL lists of an existing
entry, and requires the caller to have owner privileges for that entry.

While modifying an existing language has some use in development scenarios,
in typical usage all the "replaced" values come from pg_pltemplate so there
will be no actual change in the language definition.  The reason for adding
this is mainly to allow programs to ensure that a language exists without
triggering an error if it already does exist.

This commit just adds and documents the new option.  A followon patch
will use it to clean up some unpleasant cases in pg_dump and pg_regress.