Darwin's libedit; per my proposal last August.  Also, suppress cast-away-
const warnings.

We have once or twice seen failures suggesting that control didn't get
to the exception block before the timeout elapsed, which is unlikely
but not impossible in a parallel regression test (with a dozen other
backends competing for cycles).  This change doesn't completely prevent
the problem of course, but it should reduce the probability enough that
we don't see it anymore.  Per buildfarm results.

symlink is kept for now for compatibility.  To call single-user mode, use
postgres --single.

SQLSTATEs, fix some documentation problems.

leading zeroes from the SQLSTATE codes.  They're strings, people,
not numbers.

docs for DROP ... IF EXISTS for the following cases:
  language, tablespace, trigger, rule, opclass, function, aggregate. operator, and cast.

> 		o Allow PL/python to composite types and result sets
> 		  once buggy assert-enabled versions of python can be detected
>
> 		  http://archives.postgresql.org/pgsql-patches/2006-04/msg00087.php

>
> * Fix CREATE CAST on DOMAINs
>
>   http://archives.postgresql.org/pgsql-hackers/2006-05/msg00072.php

Backpatch documentation addition to 8.1.X.

> 		  http://archives.postgresql.org/pgsql-bugs/2006-04/msg00248.php

DROP ... IF EXISTS for the following cases:
  language, tablespace, trigger, rule, opclass, function, aggregate. operator, and cast.

>   http://archives.postgresql.org/pgsql-general/2005-08/msg01432.php

>   http://archives.postgresql.org/pgsql-hackers/2006-03/msg00586.php

> * Consider shrinking expired tuples to just their headers
>   http://archives.postgresql.org/pgsql-patches/2006-03/msg00142.php

by creating a reference-count mechanism, similar to what we did a long time
ago for catcache entries.  The back branches have an ugly solution involving
lots of extra copies, but this way is more efficient.  Reference counting is
only applied to tupdescs that are actually in caches --- there seems no need
to use it for tupdescs that are generated in the executor, since they'll go
away during plan shutdown by virtue of being in the per-query memory context.
Neil Conway and Tom Lane

* Auto-fill the free space map by scanning the buffer cache or by
  checking pages written by the background writer

>
>   http://archives.postgresql.org/pgsql-hackers/2006-02/msg01125.php
>

> * Add support for public SYNONYMS
>
>   http://archives.postgresql.org/pgsql-hackers/2006-03/msg00519.php

>
>                http://archives.postgresql.org/pgsql-patches/2006-02/msg00288.php

> 		o Fix problems with RETURN NEXT on tables with
> 		  dropped/added columns after function creation
>
> 		  http://archives.postgresql.org/pgsql-patches/2006-02/msg00165.php

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

>
> 		  http://archives.postgresql.org/pgsql-hackers/2006-01/msg00250.php
>

Magnus Hagander

< 		  get_employee_salary(emp_id AS 12345, tax_year AS 2001)
> 		  get_employee_salary(12345 AS emp_id, 2001 AS tax_year)

close.

ITAGAKI Takahiro

less than one row is returned by the SELECT, for Oracle PL/SQL
compatibility.

Improve SELECT INTO documentation.

Matt Miller

non-PostgreSQL libraries cannot be loaded using this capability.

< 		  get_employee_salary(emp_id => 12345, tax_year => 2001)
> 		  get_employee_salary(emp_id AS 12345, tax_year AS 2001)

description.

Nis Jorgensen

>
> 		o Fix memory leak from exceptions
>
> 		  http://archives.postgresql.org/pgsql-performance/2006-06/msg00305.php

section into PL/pgSQL and non-PL/pgSQL sections:

< 	o Fix PL/pgSQL RENAME to work on variables other than OLD/NEW
< 	o Allow function parameters to be passed by name,
< 	  get_employee_salary(emp_id => 12345, tax_year => 2001)
< 	o Add Oracle-style packages
< 	o Add table function support to pltcl, plpython
< 	o Add capability to create and call PROCEDURES
< 	o Allow PL/pgSQL to handle %TYPE arrays, e.g. tab.col%TYPE[]
< 	o Allow function argument names to be statements from PL/PgSQL
< 	o Add MOVE to PL/pgSQL
< 	o Add support for polymorphic arguments and return types to
< 	  languages other than PL/PgSQL
< 	o Add support for OUT and INOUT parameters to languages other
< 	  than PL/PgSQL
< 	o Add single-step debugging of PL/PgSQL functions
< 	o Allow PL/PgSQL to support WITH HOLD cursors
< 	o Allow PL/PgSQL RETURN to return row or record functions
<
< 	  http://archives.postgresql.org/pgsql-patches/2005-11/msg00045.php
> 	o PL/pgSQL
> 		o Fix RENAME to work on variables other than OLD/NEW
> 		o Allow function parameters to be passed by name,
> 		  get_employee_salary(emp_id => 12345, tax_year => 2001)
> 		o Add Oracle-style packages
> 		o Allow handling of %TYPE arrays, e.g. tab.col%TYPE[]
> 		o Allow listing of record column names, and access to
> 		  record columns via variables, e.g. columns := r.(*),
> 		  tval2 := r.(colname)
>
> 		  http://archives.postgresql.org/pgsql-patches/2005-07/msg00458.php
> 		  http://archives.postgresql.org/pgsql-patches/2006-05/msg00302.php
> 		  http://archives.postgresql.org/pgsql-patches/2006-06/msg00031.php
>
> 		o Add MOVE
> 		o Add single-step debugging of functions
> 		o Add support for WITH HOLD cursors
> 		o Allow PL/RETURN to return row or record functions
>
> 		  http://archives.postgresql.org/pgsql-patches/2005-11/msg00045.php
>
>
> 	o Other
> 		o Add table function support to pltcl, plpython
> 		o Add support for polymorphic arguments and return types to
> 		  languages other than PL/PgSQL
> 		o Add capability to create and call PROCEDURES
> 		o Add support for OUT and INOUT parameters to languages other
> 		  than PL/PgSQL

> 	o Allow PL/PgSQL RETURN to return row or record functions
>
> 	  http://archives.postgresql.org/pgsql-patches/2005-11/msg00045.php

<
< * Consider padding the spinlock structure to have spinlock registers
<   on different CPU cache line
<
<   http://archives.postgresql.org/pgsql-hackers/2005-10/msg00498.php

remove the infrastructure needed to enforce the limit, ie, the global
LRU list of cache entries.  On small-to-middling databases this wins
because maintaining the LRU list is a waste of time.  On large databases
this wins because it's better to keep more cache entries (we assume
such users can afford to use some more per-backend memory than was
contemplated in the Berkeley-era catcache design).  This provides a
noticeable improvement in the speed of psql \d on a 10000-table
database, though it doesn't make it instantaneous.

While at it, use per-catcache settings for the number of hash buckets
per catcache, rather than the former one-size-fits-all value.  It's a
bit silly to be using the same number of hash buckets for, eg, pg_am
and pg_attribute.  The specific values I used might need some tuning,
but they seem to be in the right ballpark based on CATCACHE_STATS
results from the standard regression tests.