< 	o Consider invalidating the cache or keeping seperate cached
< 	  copies when search_path changes
> 	o Consider keeping seperate cached copies when search_path changes

>
> * Consider transaction start/end performance improvements
>
>   http://archives.postgresql.org/pgsql-hackers/2007-07/msg00948.php
>   http://archives.postgresql.org/pgsql-hackers/2008-03/msg00361.php

a NULL value.  Per bug #4058.

strings.  This patch introduces four support functions cstring_to_text,
cstring_to_text_with_len, text_to_cstring, and text_to_cstring_buffer, and
two macros CStringGetTextDatum and TextDatumGetCString.  A number of
existing macros that provided variants on these themes were removed.

Most of the places that need to make such conversions now require just one
function or macro call, in place of the multiple notational layers that used
to be needed.  There are no longer any direct calls of textout or textin,
and we got most of the places that were using handmade conversions via
memcpy (there may be a few still lurking, though).

This commit doesn't make any serious effort to eliminate transient memory
leaks caused by detoasting toasted text objects before they reach
text_to_cstring.  We changed PG_GETARG_TEXT_P to PG_GETARG_TEXT_PP in a few
places where it was easy, but much more could be done.

Brendan Jurd and Tom Lane

> * -Avoid tuple some tuple copying in sort routines

identical to tuplestore_puttuple(), except it operates on arrays of
Datums + nulls rather than a fully-formed HeapTuple. In several places
that use the tuplestore API, this means we can avoid creating a
HeapTuple altogether, saving a copy.

	* Simplify integer cross-data-type operators

>
> * Add SQL-standard array_agg() and unnest() array functions
>
>   http://archives.postgresql.org/pgsql-hackers/2008-01/msg01017.php
>

>
> 	o Consider invalidating the cache or keeping seperate cached
> 	  copies when search_path changes
>
> 	  http://archives.postgresql.org/pgsql-hackers/2008-01/msg01009.php

>
> * Add more cross-data-type operators
>
>   http://archives.postgresql.org/pgsql-bugs/2008-01/msg00189.php

> * Detect deadlocks involving LockBufferForCleanup()
>
>   http://archives.postgresql.org/pgsql-hackers/2008-01/msg00873.php

>
> 	o Improve display if enums
>
> 	  http://archives.postgresql.org/pgsql-hackers/2008-01/msg00826.php
>
>

>
> 	o Fix port/rint.c to be spec-compliant
>
> 	  http://archives.postgresql.org/pgsql-hackers/2008-01/msg00808.php

>
> * Consider sorting entries before inserting into btree index
>
>   http://archives.postgresql.org/pgsql-general/2008-01/msg01010.php

>
> * Improve detection of shared memory segments being used by other
>   FreeBSD jails
>
>   http://archives.postgresql.org/pgsql-hackers/2008-01/msg00656.php

>
> * Move pgfoundry's xlogdump to /contrib and have it rely more closely
>   on the WAL backend code
>
>   http://archives.postgresql.org/pgsql-hackers/2007-11/msg00035.php
>

>
> * Have resource managers report the duration of their status changes
>
>   http://archives.postgresql.org/pgsql-hackers/2007-10/msg01468.php

>
> * Be more aggressive about creating WAL files
>
>   http://archives.postgresql.org/pgsql-hackers/2007-10/msg01325.php

> 	o Prevent concurrent CREATE TABLE table1 from sometimes returning
> 	  a cryptic error message
>
> 	  http://archives.postgresql.org/pgsql-bugs/2007-10/msg00169.php

>
> * Have /contrib/dblink reuse unnamed connections
>
>   http://archives.postgresql.org/pgsql-hackers/2007-10/msg00895.php

> * Remove old-style routines for manipulating tuples
>
>   http://archives.postgresql.org/pgsql-hackers/2007-10/msg00851.php

>
> * Create three versions of libpgport to simplify client code
>
>   http://archives.postgresql.org/pgsql-hackers/2007-10/msg00154.php
>

>
> * Fix regular expression bug when using complex back-references
>
>   http://archives.postgresql.org/pgsql-bugs/2007-10/msg00000.php

>
> * Allow xml arrays to be cast to other data types
>
>   http://archives.postgresql.org/pgsql-hackers/2007-09/msg00981.php
>   http://archives.postgresql.org/pgsql-hackers/2007-10/msg00231.php
>   http://archives.postgresql.org/pgsql-hackers/2007-11/msg00471.php
>

knowledge up through any joins it participates in.  We were doing that already
in some special cases but not in the general case.  Also, defend against zero
row estimates for the input relations in cost_mergejoin --- this fix may have
eliminated the only scenario in which that can happen, but be safe.  Per
report from Alex Solovey.

large numbers of dependencies on a role that couldn't be dropped.
Per a comment from Alvaro.

friends.  Avoid double translation of some messages, ensure other messages
are exposed for translation (and make them follow the style guidelines),
avoid unsafe passing of an unpredictable message text as a format string.

>
> * Research reducing deTOASTing in more places
>
>   http://archives.postgresql.org/pgsql-hackers/2007-09/msg00895.php

query texts only to the server log.  This eliminates the issue of possible
leaking of security-sensitive data in other sessions' queries.  Since the
log is presumed secure, we can now log the queries of all sessions involved
in the deadlock, whether or not they belong to the same user as the one
reporting the failure.

errdetail except the string goes only to the server log, replacing the normal
errdetail there.  This provides a reasonably clean way of dealing with error
details that are too security-sensitive or too bulky to send to the client.

This commit just adds the infrastructure --- actual uses to follow.

* SMP scalability improvements

>   http://archives.postgresql.org/pgsql-hackers/2007-09/msg00206.php

* SMP scalability improvements

>   http://archives.postgresql.org/pgsql-hackers/2008-03/msg00361.php

>
> * SMP scalability improvements
>
>   http://archives.postgresql.org/pgsql-hackers/2007-07/msg00439.php

* Allow statistics last vacuum/analyze execution times to be displayed
  without requiring stats_row_level to be enabled

>
>   http://archives.postgresql.org/pgsql-docs/2007-04/msg00028.php
>

> * Improve reporting of UNION type mismatches
>
>   http://archives.postgresql.org/pgsql-hackers/2007-04/msg00944.php
>   http://archives.postgresql.org/pgsql-hackers/2008-03/msg00597.php