strange coding practices.

thought that it didn't have to reposition the underlying tuplestore if the
portal is atEnd.  But this is not so, because tuplestores have separate read
and write cursors ... and the read cursor hasn't moved from the start.
This mistake explains bug #2970 from William Zhang.

Note: the coding here is pretty inefficient, but given that no one has noticed
this bug until now, I'd say hardly anyone uses the case where the cursor has
been advanced before being persisted.  So maybe it's not worth worrying about.

    <P>USA saving time changes are included in PostgreSQL release 8.0.[4+],
    and all later major releases, e.g. 8.1.  Canada and Western Australia
    changes are included in 8.0.[10+], 8.1.[6+], and all later major
    releases.  PostgreSQL releases prior to 8.0 use the operating system's
    timezone database for daylight saving information.</P>

out that ExecEvalVar and friends don't necessarily have access to a tuple
descriptor with correct typmod: it definitely can contain -1, and possibly
might contain other values that are different from the Var's value.
Arguably this should be cleaned up someday, but it's not a simple change,
and in any case typmod discrepancies don't pose a security hazard.
Per reports from numerous people :-(

I'm not entirely sure whether the failure can occur in 8.0 --- the simple
test cases reported so far don't trigger it there.  But back-patch the
change all the way anyway.

* -Move NAMEDATALEN from postgres_ext.h to pg_config_manual.h
* Consider making NAMEDATALEN more configurable in future releases

used to be part of libpq's exported interface many releases ago, but now
it's no longer necessary to make it accessible to clients.

had stopped working for tables buried inside views or sub-selects.  This is
because I had gotten rid of the simplify_jointree() preprocessing step, and
optimize_minmax_aggregates() wasn't smart enough to deal with a non-canonical
FromExpr.  Per gripe from Bill Howe.

merges/hashes property settings.

markup's broken.  So just remove it...

that aren't turned into true joins).  Since this is the last missing bit of
infrastructure, go ahead and fill out the hash integer_ops and float_ops
opfamilies with cross-type operators.  The operator family project is now
DONE ... er, except for documentation ...

> 	o Add a \set variable to control whether \s displays line numbers

> 	  Another option is to add \# which lists line numbers, and
> 	  allows command execution.
> 	  http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php

< 	o Add \# to list command history like \s, but with line numbers
> 	o Add \# to list and execute command history

Pass modern COPY syntax to backend, since copy (query) does not accept old syntax. Per complaint from Michael Fuhr.

describe the maximum size of index tuples (which is typically AM-dependent
anyway); and consequently remove the bogus deduction for "special space"
that was built into it.

Adjust TOAST_TUPLE_THRESHOLD and TOAST_MAX_CHUNK_SIZE to avoid wasting two
bytes per toast chunk, and to ensure that the calculation correctly tracks any
future changes in page header size.  The computation had been inaccurate in a
way that didn't cause any harm except space wastage, but future changes could
have broken it more drastically.

Fix the calculation of BTMaxItemSize, which was formerly computed as 1 byte
more than it could safely be.  This didn't cause any harm in practice because
it's only compared against maxalign'd lengths, but future changes in the size
of page headers or btree special space could have exposed the problem.

initdb forced because of change in TOAST_MAX_CHUNK_SIZE, which alters the
storage of toast tables.

threshold for tuple length.  On 4-byte-MAXALIGN machines, the toast code
creates tuples that have t_len exactly TOAST_TUPLE_THRESHOLD ... but this
number is not itself maxaligned, so if heap_insert maxaligns t_len before
comparing to TOAST_TUPLE_THRESHOLD, it'll uselessly recurse back to
tuptoaster.c, wasting cycles.  (It turns out that this does not happen on
8-byte-MAXALIGN machines, because for them the outer MAXALIGN in the
TOAST_MAX_CHUNK_SIZE macro reduces TOAST_MAX_CHUNK_SIZE so that toast tuples
will be less than TOAST_TUPLE_THRESHOLD in size.  That MAXALIGN is really
incorrect, but we can't remove it now, see below.)  There isn't any particular
value in maxaligning before comparing to the thresholds, so just don't do
that, which saves a small number of cycles in itself.

These numbers should be rejiggered to minimize wasted space on toast-relation
pages, but we can't do that in the back branches because changing
TOAST_MAX_CHUNK_SIZE would force an initdb (by changing the contents of toast
tables).  We can move the toast decision thresholds a bit, though, which is
what this patch effectively does.

Thanks to Pavan Deolasee for discovering the unintended recursion.

Back-patch into 8.2, but not further, pending more testing.  (HEAD is about
to get a further patch modifying the thresholds, so it won't help much
for testing this form of the patch.)

>
> * Allow custom variable classes that can restrict who can set the values
>
>   http://archives.postgresql.org/pgsql-hackers/2006-11/msg00911.php
>

Backpatch to 8.2.X.

  errhint("Consider using VACUUM FULL on this relation or increasing the configuration parameter \"max_fsm_pages\".")));

* Allow sequential scans to take advantage of other concurrent
  sequential scans, also called "Synchronised Scanning"

>
> 	o Add \# to list command history like \s, but with line numbers
>
> 	  http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php
>

* Allow sequential scans to take advantage of other concurrent
  sequential scans, also called "Synchronised Scanning"
>   http://archives.postgresql.org/pgsql-patches/2006-12/msg00076.php
>   http://archives.postgresql.org/pgsql-hackers/2006-12/msg00408.php

	gmake -C src/bin install

does install a few server-only binaries.

> 	  o Allow recovery.conf to allow the same syntax as
> 	    postgresql.conf, including quoting
>
> 	    http://archives.postgresql.org/pgsql-hackers/2006-12/msg00497.php

observe the xmloption.

Reorganize the representation of the XML option in the parse tree and the
API to make it easier to manage and understand.

Add regression tests for parsing back XML expressions.

are both used.

Albe Laurenz

* Reduce checkpoint performance degredation by forcing data to disk
  more evenly

>   http://archives.postgresql.org/pgsql-patches/2006-12/msg00104.php

* Allow sequential scans to take advantage of other concurrent
  sequential scans, also called "Synchronised Scanning"
>
>   http://archives.postgresql.org/pgsql-hackers/2006-12/msg00784.php

> * Reduce checkpoint performance degredation by forcing data to disk
>   more evenly
>
>   http://archives.postgresql.org/pgsql-hackers/2006-12/msg00337.php
>   http://archives.postgresql.org/pgsql-hackers/2007-01/msg00079.php