whose prototypes include the "List" type, so it ought to include the
list header file.

made as part of the recent INCLUDING CONSTRAINTS patch. The text could
stand further improvement, but this is at least a step in the right
direction.

>   http://momjian.us/cgi-bin/pgsitc

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.