* new split algorithm (as proposed in http://archives.postgresql.org/pgsql-hackers/2006-06/msg00254.php)
  * possible call pickSplit() for second and below columns
  * add spl_(l|r)datum_exists to GIST_SPLITVEC -
    pickSplit should check its values to use already defined
    spl_(l|r)datum for splitting. pickSplit should set
    spl_(l|r)datum_exists to 'false' (if they was 'true') to
    signal to caller about using spl_(l|r)datum.
  * support for old pickSplit(): not very optimal
    but correct split
* remove 'bytes' field from GISTENTRY: in any case size of
  value is defined by it's type.
* split GIST_SPLITVEC to two structures: one for using in picksplit
  and second - for internal use.
* some code refactoring
* support of subsplit to rtree opclasses

TODO: add support of subsplit to contrib modules

versions very unhappy, and shouldn't be there anyway.

for every command, default to on.

and batch files.  Should reduce memory and I/O demands for such joins.

this someday, but right now it seems that posix_fadvise is immature to
the point of being broken on many platforms ... and we don't have any
benchmark evidence proving it's worth spending time on.

	* %Disallow changing default expression of a SERIAL column

Dhanaraj M

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