< 		o Add Oracle-style packages
> 		o Add Oracle-style packages  (Pavel)
> * Pavel is Pavel Stehule <pavel.stehule@hotmail.com>

< 	  o Automatically force archiving of partially-filled WAL files when
> 	  o -Automatically force archiving of partially-filled WAL files when
<
< 	    Doing this will allow administrators to know more easily when
< 	    the archive contains all the files needed for point-in-time
< 	    recovery.
< 	    http://archives.postgresql.org/pgsql-patches/2005-04/msg00121.php
<
< 	  o Add reporting of the current WAL file and offset, perhaps as
> 	  o -Add reporting of the current WAL file and offset, perhaps as
<
< 	    The offset allows parts of a WAL file to be archived using
< 	    an external program.
<

< * Allow protocol-level BIND parameter values to be logged
<
<   http://archives.postgresql.org/pgsql-hackers/2006-02/msg00165.php
> * -Allow protocol-level BIND parameter values to be logged, if text mode

	o  print user name for all
	o  print portal name if defined for all
	o  print query for all
	o  reduce log_statement header to single keyword
	o  print bind parameters as DETAIL if text mode

to happen automatically during pg_stop_backup().  Add some functions for
interrogating the current xlog insertion point and for easily extracting
WAL filenames from the hex WAL locations displayed by pg_stop_backup
and friends.  Simon Riggs with some editorialization by Tom Lane.

>   http://archives.postgresql.org/pgsql-hackers/2006-08/msg00174.php

the DROP pass rather than the ADD_CONSTR pass.  On examining the code I
think this was just an oversight rather than intentional, and it seems
to satisfy the principle of least surprise better than the alternative
solution that was discussed.  Add an example to the ref page showing how
to do ALTER TYPE and update the default in one command.  Per gripe from
Markus Bertheau that that wasn't possible.

as grantees, not PUBLIC ... and you can't say GROUP either.  Noted by
Brian Hurt.

< 	o Add COPY TO STDIN / STDOUT handling
> 	o Add COPY TO STDIN handling

> 	o In rules, allow VALUES() to contain a mixture of 'old' and 'new'
> 	  references

        o -Allow INSERT INTO tab (col1, ..) VALUES (val1, ..), (val2, ..)

of the text where appropiate.

if table creation failed (the table already exists).

Martin Pitt

< 	o %Allow pg_dump to use multiple -t and -n switches  [pg_dump]
<
< 	  http://archives.postgresql.org/pgsql-patches/2006-01/msg00190.php
<
> 	o -Allow pg_dump to use multiple -t and -n switches, exclusion
> 	   ability, and regular expression object matching

and -N options to exclude objects.  Also support regular expressions for
option object names.

Greg Sabino Mullane

Joshua D. Drake
Robert Treat

> * Consider compressed annealing to search for query plans
>
>   This might replace GEQO, http://sixdemonbag.org/Djinni.

(table or index) before trying to open its relcache entry.  This fixes
race conditions in which someone else commits a change to the relation's
catalog entries while we are in process of doing relcache load.  Problems
of that ilk have been reported sporadically for years, but it was not
really practical to fix until recently --- for instance, the recent
addition of WAL-log support for in-place updates helped.

Along the way, remove pg_am.amconcurrent: all AMs are now expected to support
concurrent update.

created in the bootstrap phase proper, rather than added after-the-fact
by initdb.  This is cleaner than before because it allows us to retire the
undocumented ALTER TABLE ... CREATE TOAST TABLE command, but the real reason
I'm doing it is so that toast tables of shared catalogs will now have
predetermined OIDs.  This will allow a reasonably clean solution to the
problem of locking tables before we load their relcache entries, to appear
in a forthcoming patch.

> * Consider detoasting keys before sorting

> * Add column to pg_stat_activity that shows the progress of long-running
>   commands like CREATE INDEX and VACUUM

> * Add support for SQL-standard GENERATED/IDENTITY columns
>
>   http://archives.postgresql.org/pgsql-hackers/2006-07/msg00543.php

> * Allow DISTINCT to work in multiple-argument aggregate calls
< 	o Allow UPDATE to handle complex aggregates [update]?

the float8 versions of the aggregates, which is all that the standard requires.
Sergey's original patch also provided versions using numeric arithmetic,
but given the size and slowness of the code, I doubt we ought to include
those in core.

server-side character set.

< * Tatsuo is Tatsuo Ishii <t-ishii@sra.co.jp> of Software Research Assoc.
> * Tatsuo is Tatsuo Ishii <ishii@sraoss.co.jp> of SRA OSS, Inc. Japan

>
>           A subselect can also be used as the value source.

the opportunity to treat COUNT(*) as a zero-argument aggregate instead
of the old hack that equated it to COUNT(1); this is materially cleaner
(no more weird ANYOID cases) and ought to be at least a tiny bit faster.
Original patch by Sergey Koposov; review, documentation, simple regression
tests, pg_dump and psql support by moi.

Albe Laurenz

< 	  o Allow point-in-time recovery to archive partially filled
< 	    write-ahead logs? [pitr]
> 	  o Add command to archive partially filled write-ahead logs? [pitr]
< 	    of a disk failure. This could be triggered by a user command or
< 	    a timer.
> 	    of a disk failure.
< 	    recovery.  A function call to do this would also be useful.
> 	    recovery.
> 	  o Add reporting of the current WAL file and offset, perhaps as
> 	    part of partial log file archiving
>
> 	    The offset allows parts of a WAL file to be archived using
> 	    an external program.
>
< 	  o Add reporting of the current WAL file and offset, perhaps as
< 	    part of partial log file archiving
<
< 	    The offset allows parts of a WAL file to be archived using
< 	    an external program.

upcoming units feature.

> * -Change LIMIT/OFFSET and FETCH/MOVE to use int8

>
> 	    The offset allows parts of a WAL file to be archived using
> 	    an external program.

< 	  o Add reporting of the current WAL file, perhaps as part of
< 	    partial log file archiving
> 	  o Add reporting of the current WAL file and offset, perhaps as
> 	    part of partial log file archiving

< 	    write-ahead logs [pitr]
> 	    write-ahead logs? [pitr]
< 	    recovery.
> 	    recovery.  A function call to do this would also be useful.