per-tuple space overhead for sorts in memory.  I chose to replace the
previous patch that tried to write out the bare minimum amount of data
when sorting on disk; instead, just dump the MinimalTuples as-is.  This
wastes 3 to 10 bytes per tuple depending on architecture and null-bitmap
length, but the simplification in the writetup/readtup routines seems
worth it.

> * -Disallow changing DEFAULT expression of a SERIAL column

< * -Disallow changing DEFAULT expression of a SERIAL column
> * %Disallow changing DEFAULT expression of a SERIAL column

analyzing, so that future analyze threshold calculations don't get confused.
Also, make sure we correctly track the decrease of live tuples cause by
deletes.

Per report from Dylan Hansen, patches by Tom Lane and me.

Greg Stark

< * %Disallow changing DEFAULT expression of a SERIAL column?
<
<   This should be done only if the existing SERIAL problems cannot be
<   fixed.
<
> * -Disallow changing DEFAULT expression of a SERIAL column

Dhanaraj M

Hiroshi Saito

tuples with less header overhead than a regular HeapTuple, per my
recent proposal.  Teach TupleTableSlot code how to deal with these.
As proof of concept, change tuplestore.c to store MinimalTuples instead
of HeapTuples.  Future patches will expand the concept to other places
where it is useful.

directory, not in device root, for permission reasons.

Backpatch to 8.1.X.

> 	o -Add PQescapeIdentifier()

Christopher Kings-Lynne

will be expanded to a list of their member fields, rather than creating
a nested rowtype field as formerly.  (The old behavior is still available
by omitting '.*'.)  This syntax is not allowed by the SQL spec AFAICS,
so changing its behavior doesn't violate the spec.  The new behavior is
substantially more useful since it allows, for example, triggers to check
for data changes with 'if row(new.*) is distinct from row(old.*)'.  Per
my recent proposal.

relevant location.

> * Bruce is Bruce Momjian <bruce@momjian.us> of EnterpriseDB

palloc() will normally round allocation requests up to the next power of 2,
so make dynahash choose allocation sizes that are as close to a power of 2
as possible.
Back-patch to 8.1 --- the problem exists further back, but a much larger
patch would be needed and it doesn't seem worth taking any risks.

< * Reuse index tuples that point to rows that are not visible to anyone?
> * Reuse index tuples that point to heap tuples that are not visible to
>   anyone?

opposed to what other versions apparently do, so it's not safe to print an
error message.  Besides, getopt_long itself already did, so it's redundant
anyway.

PGDG:

> Yes. In fact the copyright belongs to credativ GmbH the company that
> paid Carsten for his work. As you may or may not know I'm the CEO of
> that company and can assure you that his work was contributed to the
> PostgreSQL project.

Magnus Hagander

After updating to the latest cvs, and also building most of the addons
(like PLs), the following patch is neededf for win32 + Visual C++.

* Switch to use the new win32 semaphore code
* Rename win32_open to pgwin32_open. win32_open collides with symbols
defined in Perl. MingW didn't detect ig, MSVC did. And it's a bit too
generic a name to export globally, imho...
* Python defines some partially broken #pragmas in the headers when
doing a debug build. Workaround.

Magnus Hagander

< * Allow heap reuse of UPDATEd rows if old and new versions are on the
<   same heap page?
> * Allow heap reuse of UPDATEd rows if no indexed columns are changed,
>   and old and new versions are on the same heap page?
<   This is possible for same-page updates because a single index row
<   can point to both old and new values.
>   While vacuum handles DELETEs fine, updating of non-indexed columns, like
>   counters, are difficult for VACUUM to handle efficiently.  This method
>   is possible for same-page updates because a single index row can be
>   used to point to both old and new values.

>
> * Allow heap reuse of UPDATEd rows if old and new versions are on the
>   same heap page?
>
>   This is possible for same-page updates because a single index row
>   can point to both old and new values.
>   http://archives.postgresql.org/pgsql-hackers/2006-06/msg01305.php

and there was some question about its copyright status.

backup history file.  Bug introduced by the 8.1 change to make pg_stop_backup
delete older history files.  Per report from Masao Fujii.

setup_win32_locks() call formerly was, to ensure that cancelConnLock is
valid when it needs to be.  Per Yoshiyuki Asaba.

aggregates.  We just disallowed that, and AFAICS there should be no other
cases where direct (non-aggregated) references to input columns are allowed
in a query with aggregation and no GROUP BY.

This is disallowed by the SQL spec because it doesn't have any very sensible
interpretation.  Historically Postgres has allowed it but behaved strangely.
As of PG 8.1 a server crash is possible if the MIN/MAX index optimization gets
applied; rather than try to "fix" that, it seems best to just enforce the
spec restriction.  Per report from Josh Drake and Alvaro Herrera.

Eliminate a gratuitously different wording of the 'cannot use aggregate function in check constraint' error message.