< 	o -Allow commenting of variables in postgresql.conf to restore them
> 	o Allow commenting of variables in postgresql.conf to restore them

< * Research storing only active XIDs in subtransaction cache

> * Research storing only active XIDs in subtransaction cache

>
> * Improve XML support
>
>   http://developer.postgresql.org/index.php/XML_Support

> 	  One idea is to store the header in network byte order (high bits
> 	  first), and read the high bits to determine the header length.

>   http://archives.postgresql.org/pgsql-hackers/2006-09/msg00662.php

< 	o Store disk pages with no alignment/padding?
>
> 	  This involves having the user-specified order of columns
> 	  be different from the physical order.  SELECT * would
> 	  need to reorder the physical values to match the
> 	  user-specified ordering.
>
> 	o Store disk pages with no alignment/padding?
>
> 	  This necessitates adding CPU-required padding when moving
> 	  rows from disk to memory.
>
>
> 	  http://archives.postgresql.org/pgsql-hackers/2006-09/msg00848.php
>

> * David is David Fetter <david@fetter.org>

< * Research storing disk pages with no alignment/padding
> * Consider ways of storing rows more compactly on disk
>
> 	o Store disk pages with no alignment/padding?
> 	o Reorder physical storage order to reduce padding?
> 	o Support a smaller header for short variable-length fields?
> 	o Reduce the row header size?

< * Change LIMIT/OFFSET and FETCH/MOVE to use int8

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

> * Simplify ability to create partitioned tables
>
>   This would allow creation of partitioned tables without requiring
>   creation of rules for INSERT/UPDATE/DELETE, and constraints for
>   rapid partition selection.  Options could include range and hash
>   partition selection.
>
> * Allow auto-selection of partitioned tables for min/max() operations

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

< Last updated:		Sat Sep  2 08:31:04 EDT 2006
> Last updated:		Sat Sep  2 16:31:46 EDT 2006
< 	o Allow UPDATE tab SET ROW (col, ...) = (...) for updating multiple
< 	  columns
> 	o -Allow UPDATE tab SET ROW (col, ...) = (val, ...) for updating
> 	  multiple columns
> 	o Allow UPDATE tab SET ROW (col, ...) = (SELECT...)
<           A subselect can also be used as the value source.

< 		o -Allow PL/python to composite types and result sets
> 		o -Allow PL/python to return composite types and result sets

                o -Allow PL/python to composite types and result sets

< Last updated:		Tue Aug 29 12:21:52 EDT 2006
> Last updated:		Wed Aug 30 20:34:28 EDT 2006
< 	o Allow COPY (SELECT ...) TO 'filename'
<
< 	  COPY should also be able to output views using COPY (SELECT
< 	  * FROM view) TO 'filename' internally.
< 	  http://archives.postgresql.org/pgsql-patches/2005-09/msg00148.php
> 	o -Allow COPY (SELECT ...) TO 'filename'

> 	o Turn on by default

> 	  http://people.planetpostgresql.org/greg/index.php?/archives/2006/06/10.html
>

> 	o Allow DEFERRABLE and end-of-statement UNIQUE constraints?
>
> 	  This would allow UPDATE tab SET col = col + 1 to work if col has
> 	  a unique index.  Currently, uniqueness checks are done while the
> 	  command is being executed, rather than at the end of the statement
> 	  or transaction.
>
<
< * Allow DEFERRABLE and end-of-statement UNIQUE constraints?
<
<   This would allow UPDATE tab SET col = col + 1 to work if col has
<   a unique index.  Currently, uniqueness checks are done while the
<   command is being executed, rather than at the end of the statement
<   or transaction.

< * Allow DEFERRABLE UNIQUE constraints?
> * Allow DEFERRABLE and end-of-statement UNIQUE constraints?
>
>   This would allow UPDATE tab SET col = col + 1 to work if col has
>   a unique index.  Currently, uniqueness checks are done while the
>   command is being executed, rather than at the end of the statement
>   or transaction.
>

<
> * Implement SQL:2003 window functions

> * Allow inlining of set-returning functions

< * All backends running as threads in a single process (not want)
> * All backends running as threads in a single process (not wanted)
< * Optimizer hints (not want)
> * Optimizer hints (not wanted)
>
> * Allow AS in "SELECT col AS label" to be optional (not wanted)
>
>   Because we support postfix operators, it isn't possible to make AS
>   optional and continue to use bison.
>   http://archives.postgresql.org/pgsql-sql/2006-08/msg00164.php

< 	o Allow COPY to output from SELECT
> 	o Allow COPY (SELECT ...) TO 'filename'
< 	  COPY should also be able to output views.
> 	  COPY should also be able to output views using COPY (SELECT
> 	  * FROM view) TO 'filename' internally.

>
>   These would be for application use, not for use by pg_dump.
>

< 	o Add a function to support Parse/DescribeStatement capability
> 	o -Add a function to support Parse/DescribeStatement capability

< * %Disallow changing DEFAULT expression of a SERIAL column?
<
<   This should be done only if the existing SERIAL problems cannot be
<   fixed.
<
< * %Disallow ALTER SEQUENCE changes for SERIAL sequences because pg_dump
<   does not dump the changes

< * Add support for arrays of domains
> 	o Add support for arrays of domains
> 	o Add support for arrays of complex types

> * Support a data type with specific enumerated values (ENUM)
>
>   http://archives.postgresql.org/pgsql-hackers/2006-08/msg00979.php

> * Add support for arrays of domains

< 	o Allow INSERT/UPDATE ... RETURNING new.col or old.col
<
< 	  This is useful for returning the auto-generated key for an INSERT.
< 	  One complication is how to handle rules that run as part of
< 	  the insert.
< 	  http://archives.postgresql.org/pgsql-patches/2005-07/msg00568.php
> 	o -Allow INSERT/UPDATE ... RETURNING new.col or old.col

< 	o %Allow commenting of variables in postgresql.conf to restore them
> 	o -Allow commenting of variables in postgresql.conf to restore them

< * Allow encoding on a per-column basis
> * Allow encoding on a per-column basis optionally using the ICU library:
>   http://archives.postgresql.org/pgsql-patches/2005-08/msg00309.php
>   http://archives.postgresql.org/pgsql-patches/2006-03/msg00233.php

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

> 	  http://archives.postgresql.org/pgsql-performance/2004-08/msg00349.php

>
>
> Features We Do _Not_ Want
> =========================
>
> * All backends running as threads in a single process (not want)
>
>   This eliminates the process protection we get from the current setup.
>   Thread creation is usually the same overhead as process creation on
>   modern systems, so it seems unwise to use a pure threaded model.
>
> * Optimizer hints (not want)
>
>   Optimizer hints are used to work around problems in the optimizer.  We
>   would rather have the problems reported and fixed.
>   http://archives.postgresql.org/pgsql-hackers/2006-08/msg00506.php

< 		  A package would be a schema with public/private variables,
> 		  A package would be a schema with session-local variables,
> 		  http://archives.postgresql.org/pgsql-hackers/2006-08/msg00384.php

< 		  A package would be a schema with its own variables,
< 		  private functions, and initialization functions.  It
> 		  A package would be a schema with public/private variables,
> 		  public/private functions, and initialization functions.  It