tuple hash table entries.  This addresses the problem previously noted
that use of a 'physical tlist' in the input scan node could bloat the
hash table entries far beyond what the planner expects.  It's a better
answer than my previous thought of undoing the physical tlist optimization,
because we can also remove columns that are needed to compute the aggregate
functions but aren't part of the grouping column set.

< 		o Add support for WITH HOLD cursors
> 		o Add support for WITH HOLD and SCROLL cursors
>
> 		  PL/pgSQL cursors should support the same syntax as
> 		  backend cursors.
>

Viktor Vislobokov

* 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