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.

Kevin Grittner

text output mode, like we do in custom output mode.

Jim Cox

output.  Per bug #5339, Perl 5.11 has changed the format of that output
enough to break the previous coding.

Alex Hunsaker

"dumping data out of order is not supported" to "restoring data out of order
is not supported", because you get that error during pg_restore not pg_dump.
Also fix some comments that didn't look so good after being pgindented as
perhaps they did originally.

improve documentation, and add C comment.

the client encoding.

statistics.

to_char with HH, e.g.

	to_char(interval '0d 0h 12m 44s', 'DD HH24 MI SS');

now returns:

	 00 00 12 44

not:

	 00 12 12 44

format.

Pavel Golub

inheritance in create table, per Andrew Dunstan.

passing being "covered elsewhere", per Dave Page.

configure warnings.

used for continuous archiving.

results claiming EBADF seem improbable enough that I'm not convinced fsync
is really returning that --- could it be failing to set errno at all?

on a platform that doesn't support this operation.  The former coding
would allow an unrelated errno to be reported, which would be quite
misleading.  Not sure if this has anything to do with the current
buildfarm failures, but it's certainly bogus as-is.

They used to be scattered between the "backup and restore" and "streaming
replication" chapters.

Add some checks that seem logically necessary, in particular let's make
real sure that HS slave sessions cannot create temp tables.  (If they did
they would think that temp tables belonging to the master's session with
the same BackendId were theirs.  We *must* not allow myTempNamespace to
become set in a slave session.)

Change setval() and nextval() so that they are only allowed on temp sequences
in a read-only transaction.  This seems consistent with what we allow for
table modifications in read-only transactions.  Since an HS slave can't have a
temp sequence, this also provides a nicer cure for the setval PANIC reported
by Erik Rijkers.

Make the error messages more uniform, and have them mention the specific
command being complained of.  This seems worth the trifling amount of extra
code, since people are likely to see such messages a lot more than before.

doc change.