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.

GSSAPI or Kerberos.

Ian Turner

of missing items and minor edits.

tuple, instead of the former cpu_tuple_cost.  It is sane to charge less than
cpu_tuple_cost because Materialize never does any qual-checking or projection,
so it's got less overhead than most plan node types.  In particular, we want
to have the same charge here as is charged for readout in cost_sort.  That
avoids the problem recently exhibited by Teodor wherein the planner prefers
a useless sort over a materialize step in a context where a lot of rescanning
will happen.  The rescan costs should be just about the same for both node
types, so make their estimates the same.

Not back-patching because all of the current logic for rescan cost estimates
is new in 9.0.  The old handling of rescans is sufficiently not-sane that
changing this in that structure is a bit pointless, and might indeed cause
regressions.