be catching stderr output, and we are not ourselves the
syslogger. Otherwise, go directly to stderr.
Bug noticed by Tom Lane.
Backpatch as far as 8.0.

Minor rearrangements to make a few tests in a more logical order.

a MIN or MAX aggregate call into an indexscan: the initplan is being made at
the current query nesting level and so we shouldn't increment query_level.
Though usually harmless, this mistake could lead to bogus "plan should not
reference subplan's variable" failures on complex queries.  Per bug report
from David Sanchez i Gregori.

some platforms and possibly a bug.  Per report from Stefan and subsequent
discussion.

Patch from Tom.

>
> 	o Allow GLOBAL temporary tables to exist as empty by default in
> 	  all sessions
>
> 	  http://archives.postgresql.org/pgsql-hackers/2007-07/msg00006.php
>

referencing table does not change the tuple's FK column(s), we don't bother
to check the PK table since the constraint was presumably already valid.
However, the check is still necessary if the tuple was inserted by our own
transaction, since in that case the INSERT trigger will conclude it need not
make the check (since its version of the tuple has been deleted).  We got this
right for simple cases, but not when the insert and update are in different
subtransactions of the current top-level transaction; in such cases the FK
check would never be made at all.  (Hence, problem dates back to 8.0 when
subtransactions were added --- it's actually the subtransaction version of a
bug fixed in 7.3.5.)  Fix, and add regression test cases.  Report and fix by
Affan Salman.

meaningful site.

based in part on an earlier patch from Trevor Hardcastle, and reviewed
by myself.

been broken since forever, but was not noticed because people seldom look
at raw parse trees.  AFAIK, no impact on users except that debug_print_parse
might fail; but patch it all the way back anyway.  Per report from Jeff Ross.

> * Allow multiple indexes to be created concurrently, ideally via a
>   single heap scan, and have a restore of a pg_dump somehow use it
>
>   http://archives.postgresql.org/pgsql-general/2007-05/msg01274.php

Small blank line additions.

on other errors.

and add a note about why.  This is not tremendously important right now,
probably, but it will get more urgent if NUM_BUFFER_PARTITIONS is increased
as much as proposed.

partition locks in reverse order.

--enable-debug is used, to avoid complaints about debugging and
optimization being mutually exclusive. Patch from Stefan Kaltenbrunner.

name.  With this patch, it is always possible for the user to qualify a
plpgsql variable name if needed to avoid ambiguity.  While there is much more
work to be done in this area, this simple change removes one unnecessary
incompatibility with Oracle.  Per discussion.

int not unsigned int.  Third try to get grebe building without warnings...

spaces in them.

ISHIDA Akio

nattering about casting away volatile.  Losers.

TAS support are properly declared.

for 'bool'.  Per buildfarm warnings.

a warning but was outright wrong.

error messages look at least a little bit like the message style
guidelines say.

not-too-bright compilers.  Per buildfarm results.

three slightly different copies of this file?)

theoretically vary depending on what the compile-time locale setting is.
Hence, force it to see LC_CTYPE=C to ensure consistent build results.
(It's likely that this makes no difference in practice, since our
specification for "identifier" surely includes both ends of any possible
uppercase/lowercase pair anyway.  But it should silence warnings about
ambiguous character classes that are reported by some buildfarm members.)

sanely if the loop value overflows int32 on the way to the end value.
Avoid useless computation of "SELECT 1" when BY is omitted.  Avoid some
type-punning between Datum and int4 that dates from the original coding.

Andrew Dunstan.  Minor other improvements in documentation of integer
FOR loops.

of variable substitution and plan caching behavior in dedicated sections.
(A lot of this material existed already, but was scattered in various places
in the chapter.)  Reorganize material a little bit, mostly to try to avoid
diving into deep details in the first introductory sections.  Document some
fine points that had escaped treatment before, notably the ability to qualify
plpgsql variable names with block labels.  Some minor wordsmithing here and
there.

by Solaris 10 and possibly others.

Stefan Kaltenbrunner