* Add REPLACE or UPSERT command that does UPDATE, or on failure, INSERT
  [merge]

      o Allow row and record variables to be set to NULL constants,
        and allow NULL tests on such variables

>
> * Consider decreasing the amount of memory used by PrivateRefCount
>
>   http://archives.postgresql.org/pgsql-hackers/2006-11/msg00797.php
>   http://archives.postgresql.org/pgsql-hackers/2007-01/msg00752.php
>

> * Increase locking when DROPing objects so dependent objects cannot
>   get dropped while the DROP operation is happening
>
>   http://archives.postgresql.org/pgsql-hackers/2007-01/msg00937.php

        o Allow UPDATE/DELETE WHERE CURRENT OF cursor
> 	  http://archives.postgresql.org/pgsql-hackers/2007-01/msg01014.php

>
> * Add missing operators for geometric data types
>
>   Some geometric types do not have the full suite of geometric operators,
>   e.g. box @> point
>

< 	o Check .pgpass file permissions
>

<
> 	o Check .pgpass file permissions

> * Fix IS OF so it matches the ISO specification, and add documentation
>
>   http://archives.postgresql.org/pgsql-patches/2003-08/msg00060.php
>   http://archives.postgresql.org/pgsql-hackers/2007-02/msg00060.php

< 	o ARRAY[[1,2],[3,4]])[1] should return the same values as
< 	  ARRAY[[1,2],[3,4]])[1:1];
<

< * Consider allowing configuration of TOAST thresholds
> * Allow user configuration of TOAST thresholds

> * Consider allowing configuration of TOAST thresholds
>
>   http://archives.postgresql.org/pgsql-hackers/2007-02/msg00213.php
>

> * Allow UPDATEs on only non-referential integrity columns not to conflict
>   with referential integrity locks
>
>   http://archives.postgresql.org/pgsql-hackers/2007-02/msg00073.php

> * Allow INSERT/UPDATE ... RETURNING inside a SELECT 'FROM' clause
>
>   http://archives.postgresql.org/pgsql-general/2006-09/msg00803.php
>   http://archives.postgresql.org/pgsql-hackers/2006-10/msg00693.php
>

> * -Add ISO day of week format 'ID' to to_char() where Monday = 1

> * -Add a field 'isoyear' to extract(), based on the ISO week

< 	o Add long file support for binary pg_dump output
<
< 	  While Win32 supports 64-bit files, the MinGW API does not,
< 	  meaning we have to build an fseeko replacement on top of the
< 	  Win32 API, and we have to make sure MinGW handles it.  Another
< 	  option is to wait for the MinGW project to fix it, or use the
< 	  code from the LibGW32C project as a guide.
<
< 	  http://archives.postgresql.org/pgsql-hackers/2006-12/msg00551.php
<
> 	o -Add long file support for binary pg_dump output

<   Currently, ALTER USER and ALTER DATABASE support per-user and
>   Currently ALTER USER and ALTER DATABASE support per-user and
< 	  Currently, subtracting one date from another that crosses a
> 	  Currently subtracting one date from another that crosses a
<   Currently, SQL-language functions can only refer to parameters via $1, etc
>   Currently SQL-language functions can only refer to dollar parameters,
>   e.g. $1
<   Currently, queries prepared via the libpq API are planned on first
>   Currently queries prepared via the libpq API are planned on first
< 	  Currently, SET <tab> causes a database lookup to check all
> 	  Currently SET <tab> causes a database lookup to check all
< 	  Currently, all statement results are transferred to the libpq
> 	  Currently all statement results are transferred to the libpq

* Allow SQL-language functions to reference parameters by parameter name

  Currently SQL-language functions can only refer to parameters via $1, etc

> * Allow holdable cursors in SPI

>
> 		o Allow row and record variables to be set to NULL constants,
> 		  and allow NULL tests on such variables
>
> 		  Because a row is not scalar, do not allow assignment
> 		  from NULL-valued scalars.

> 	o Consider reducing on-disk varlena length from four to two
> 	  because a heap row cannot be more than 64k in length

>
> 	o Use LC_TIME for localized weekday/month names, rather than
> 	  LC_MESSAGES
>
> 	  http://archives.postgresql.org/pgsql-hackers/2006-11/msg00390.php

> * Clean up casting in /contrib/isn
>
>   http://archives.postgresql.org/pgsql-hackers/2006-11/msg00245.php
>

> * Improve logging of prepared statements recovered during startup
>
>   http://archives.postgresql.org/pgsql-hackers/2006-11/msg00092.php
>

* Allow SQL-language functions to return results from RETURNING queries
>
>   http://archives.postgresql.org/pgsql-hackers/2006-10/msg00665.php
>

>
>   http://archives.postgresql.org/pgsql-performance/2006-10/msg00222.php
>

* Update Bonjour to work with newer cross-platform SDK

>   http://archives.postgresql.org/pgsql-patches/2006-10/msg00048.php

> * Improve failure message when DROP DATABASE is used on a database that
>   has prepared transactions

* Update Bonjour to work with newer cross-platform SDK

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

> * Update our code to handle 64-bit timezone files to match the zic
>   source code, which now uses them

<
>   http://archives.postgresql.org/pgsql-hackers/2007-02/msg00435.php

< * Merge xmin/xmax/cmin/cmax back into three header fields
<
<   Before subtransactions, there used to be only three fields needed to
<   store these four values. This was possible because only the current
<   transaction looks at the cmin/cmax values. If the current transaction
<   created and expired the row the fields stored where xmin (same as
<   xmax), cmin, cmax, and if the transaction was expiring a row from a
<   another transaction, the fields stored were xmin (cmin was not
<   needed), xmax, and cmax. Such a system worked because a transaction
<   could only see rows from another completed transaction. However,
<   subtransactions can see rows from outer transactions, and once the
<   subtransaction completes, the outer transaction continues, requiring
<   the storage of all four fields. With subtransactions, an outer
<   transaction can create a row, a subtransaction expire it, and when the
<   subtransaction completes, the outer transaction still has to have
<   proper visibility of the row's cmin, for example, for cursors.
<
<   One possible solution is to create a phantom cid which represents a
<   cmin/cmax pair and is stored in local memory.  Another idea is to
<   store both cmin and cmax only in local memory.
<
> * -Merge xmin/xmax/cmin/cmax back into three header fields

< * Consider placing all sequences in a single table
> * Consider placing all sequences in a single table, or create a system
>   view

< * Consider placing all sequences in a single table, now that system
<   tables are full transactional
> * Consider placing all sequences in a single table

> * Consider placing all sequences in a single table, now that system
>   tables are full transactional

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

* -Move NAMEDATALEN from postgres_ext.h to pg_config_manual.h
* Consider making NAMEDATALEN more configurable in future releases