syntax summary consistent with the other SQL reference pages. Patch
from Euler Taveira de Oliveira.

> 	  http://archives.postgresql.org/pgsql-hackers/2006-09/msg01481.php

>
>   http://archives.postgresql.org/pgsql-patches/2006-09/msg00209.php
>

the input query's target list too soon, causing it to affect processing
of ORDER BY in the input query.

>
> * Set client encoding based on the client operating system encoding
>
>   Currently client_encoding is set in postgresql.conf, which
>   defaults to the server encoding.

<
> 	  http://archives.postgresql.org/pgsql-hackers/2006-09/msg01458.php

oversight in original implementation of VALUES.  Also fix an oversight
in recent addition of options to CREATE TABLE AS: they weren't getting
propagated if the query was a set-operation such as UNION.

the table being analyzed.  This prevents two ANALYZEs from running
concurrently on the same table and possibly suffering concurrent-update
failures while trying to store their results into pg_statistic.  The
downside is that a database-wide ANALYZE executed within a transaction
block will hold ShareUpdateExclusiveLock on many tables simultaneously,
which could lead to concurrency issues or even deadlock against another
such ANALYZE.  However, this seems a corner case of less importance
than getting unexpected errors from a foreground ANALYZE when autovacuum
elects to analyze the same table concurrently.  Per discussion.

after an error during VACUUM.  We have a PG_TRY block anyway around the only
call sites, so just reset it in the CATCH clause instead of having
AtEOXact_Buffers blindly do it during xact end.  I think the old code was
actively wrong for the case of a failure during ANALYZE inside a
subtransaction --- the flag wouldn't get cleared until main transaction end.
Probably not worth back-patching though.

< 	o Reorder physical storage order to reduce padding?
<
< 	  This involves having the user-specified order of columns
< 	  be different from the physical order.  SELECT * would
< 	  need to reorder the physical values to match the
< 	  user-specified ordering.
<
< 	o Store disk pages with no alignment/padding?
<
< 	  This necessitates adding CPU-required padding when moving
< 	  rows from disk to memory.
<
< 	  One idea is to store the header in network byte order (high bits
< 	  first), and read the high bits to determine the header length.
< 	  http://archives.postgresql.org/pgsql-hackers/2006-09/msg00848.php
> 	  One idea is to create zero-or-one-byte-header versions
> 	  of varlena data types.  In involves setting the high-bit and
> 	  0-127 length in the single-byte header, or clear the high bit
> 	  and store the 7-bit ASCII value in the rest of the byte.
> 	  The small-header versions have no alignment requirements.
> 	  http://archives.postgresql.org/pgsql-hackers/2006-09/msg01372.php

and create a new view pg_timezone_names that provides information about
the zones known in the 'zic' database.  Magnus Hagander, with some
additional work by Tom Lane.

alias with the old name for backwards compatibility.  Per discussion,
the old name is actively wrong because validity and well-formedness
have different meanings in XML.

per Magnus.

Includes sample standby script.

Simon Riggs

Simon Riggs

per Magnus.

comment alignment on most systems.

a schema is our own temp schema or another backend's temp schema, and use
these in place of some former kluges in information_schema.  Per my
proposal of yesterday.

< * -Allow PREPARE to automatically determine parameter types based on the SQL
<   statement (Neil)

< * -Allow protocol-level BIND parameter values to be logged, if text mode
> * -Allow protocol-level BIND parameter values to be logged

< 	o -Allow commenting of variables in postgresql.conf to restore them
> 	o Allow commenting of variables in postgresql.conf to restore them

Victor Wagner

< * Research storing only active XIDs in subtransaction cache

> * Research storing only active XIDs in subtransaction cache

>
> * Improve XML support
>
>   http://developer.postgresql.org/index.php/XML_Support

> 	  One idea is to store the header in network byte order (high bits
> 	  first), and read the high bits to determine the header length.

>   http://archives.postgresql.org/pgsql-hackers/2006-09/msg00662.php

< 	o Store disk pages with no alignment/padding?
>
> 	  This involves having the user-specified order of columns
> 	  be different from the physical order.  SELECT * would
> 	  need to reorder the physical values to match the
> 	  user-specified ordering.
>
> 	o Store disk pages with no alignment/padding?
>
> 	  This necessitates adding CPU-required padding when moving
> 	  rows from disk to memory.
>
>
> 	  http://archives.postgresql.org/pgsql-hackers/2006-09/msg00848.php
>