that are reported as "equal" by wcscoll() are checked to see if they really
are bitwise equal, and are sorted per strcmp() if not.  We made this happen
a couple of years ago in the regular code path, but it unaccountably got
left out of the Windows/UTF8 case (probably brain fade on my part at the
time).  As in the prior set of changes, affected users may need to reindex
indexes on textual columns.

Backpatch as far as 8.2, which is the oldest release we are still supporting
on Windows.

messages if the calling transaction aborts later on.  Collapsing out line
pointer redirects is a done deal as soon as we complete the page update,
so syscache *must* be notified even if the VACUUM FULL as a whole doesn't
complete.  To fix, add some functionality to inval.c to allow the pending
inval messages to be sent immediately while heap_page_prune is still
running.  The implementation is a bit chintzy: it will only work in the
context of VACUUM FULL.  But that's all we need now, and it can always be
extended later if needed.  Per my trouble report of a week ago.

* Do async I/O for faster random read-ahead of data

  Async I/O allows multiple I/O requests to be sent to the disk with
  results coming back asynchronously.

>   http://archives.postgresql.org/pgsql-performance/2007-09/msg00255.php

(probably NULL) before exiting.  Up to now it's just left the variable as it
set it, which means that after we're done processing the current client
message, ActiveSnapshot is probably pointing at garbage (because this function
is typically run in MessageContext which will get reset).  There doesn't seem
to have been any code path in which that mattered before 8.3, but now the
plancache module might try to use the stale value if the next client message
is a Bind for a prepared statement that is in need of replanning.  Per report
from Alex Hunsaker.

< * Include the symbolic SQLSTATE name in verbose error reports
<
<   http://archives.postgresql.org/pgsql-general/2007-09/msg00438.php

> * Expire published xmin for read-only and idle transactions
>
>   http://archives.postgresql.org/pgsql-hackers/2007-09/msg00343.php

pg_listener modifications commanded by LISTEN and UNLISTEN until the end
of the current transaction.  This allows us to hold the ExclusiveLock on
pg_listener until after commit, with no greater risk of deadlock than there
was before.  Aside from fixing the race condition, this gets rid of a
truly ugly kludge that was there before, namely having to ignore
HeapTupleBeingUpdated failures during NOTIFY.  There is a small potential
incompatibility, which is that if a transaction issues LISTEN or UNLISTEN
and then looks into pg_listener before committing, it won't see any resulting
row insertion or deletion, where before it would have.  It seems unlikely
that anyone would be depending on that, though.

This patch also disallows LISTEN and UNLISTEN inside a prepared transaction.
That case had some pretty undesirable properties already, such as possibly
allowing pg_listener entries to be made for PIDs no longer present, so
disallowing it seems like a better idea than trying to maintain the behavior.

>
> * Consider a special data type for regular expressions
>
>   http://archives.postgresql.org/pgsql-hackers/2007-08/msg01067.php

* Add array_accum() and array_to_set() functions for arrays

  The standards specify array_agg() and UNNEST.
  http://archives.postgresql.org/pgsql-hackers/2007-08/msg00464.php

* Consider a simplified API for full text searches

>   http://archives.postgresql.org/pgsql-hackers/2007-08/msg01067.php

>
> 	o Convert MSVC build system to remove most batch files
>
> 	  http://archives.postgresql.org/pgsql-hackers/2007-08/msg00961.php

* Add REINDEX CONCURRENTLY, like CREATE INDEX CONCURRENTLY

>   http://archives.postgresql.org/pgsql-performance/2007-08/msg00289.php

> 	o Diagnose problem where shared memory can sometimes not be
> 	  attached by postmaster children
>
> 	  http://archives.postgresql.org/pgsql-general/2007-08/msg01377.php
>

>
> * Remove use of MAKE_PTR and MAKE_OFFSET macros
>
>   http://archives.postgresql.org/pgsql-general/2007-08/msg01510.php

>
> * Add array_accum() and array_to_set() functions for arrays
>
>   http://archives.postgresql.org/pgsql-hackers/2007-08/msg00464.php

comply with TPC-B.  Per Itagaki Takahiro and discussion of bug#3681.

* Improve speed with indexes

  For large table adjustments during VACUUM FULL, it is faster to cluster
  or reindex rather than update the index.  Also, index updates can bloat
  the index.


>   http://archives.postgresql.org/pgsql-hackers/2007-08/msg00307.php

>
> * Allow domains to be cast
>
>   http://archives.postgresql.org/pgsql-hackers/2003-06/msg01206.php
>   http://archives.postgresql.org/pgsql-hackers/2007-08/msg00289.php

>
> * Consider simplifying how memory context resets handle child contexts
>
>   http://archives.postgresql.org/pgsql-patches/2007-08/msg00067.php

>   http://archives.postgresql.org/pgsql-hackers/2007-08/msg00082.php

* Consider increasing NUM_CLOG_BUFFERS

>   http://archives.postgresql.org/pgsql-performance/2007-08/msg00024.php

* Consider increasing NUM_CLOG_BUFFERS
>
>   http://archives.postgresql.org/pgsql-hackers/2007-08/msg00030.php
>

	test=> \copy billing_data from ../BillingSamplePricerFile.csv with csv
	   header quote as '"' null as 'abc' null as '123'
	\copy: parse error at "null"

Per report from Stephen Frost

        o Allow COPY in CSV mode to control whether a quoted zero-length
          string is treated as NULL

          Currently this is always treated as a zero-length string,
          which generates an error when loading into an integer column

>
> 	o Allow COPY in CSV mode to control whether "" is treated as NULL
>
> 	  http://archives.postgresql.org/pgsql-hackers/2007-07/msg00905.php

>
> 	o Improve logic of determining if an identifier is a a
> 	  variable or column name
>
> 	  http://archives.postgresql.org/pgsql-hackers/2007-07/msg00436.php

>
> * Add automated check for invalid C++ source code constructs
>
>   http://archives.postgresql.org/pgsql-patches/2007-07/msg00056.php

> * Research use of signals and sleep wake ups
>
>   http://archives.postgresql.org/pgsql-hackers/2007-07/msg00003.php

* Test to see if calling PreallocXlogFiles() from the background writer
  will help with WAL segment creation latency

  http://archives.postgresql.org/pgsql-patches/2007-06/msg00340.php

> * Consider adding buffers the background writer finds reusable to the
>   free list
>
> * Consider wither increasing BM_MAX_USAGE_COUNT improves performance
>
>   http://archives.postgresql.org/pgsql-hackers/2007-06/msg01007.php

* Reduce storage space for small NUMERICs

>   http://archives.postgresql.org/pgsql-hackers/2007-06/msg00715.php

before it goes groveling through the ProcArray.  In situations where the same
recently-committed transaction ID is checked repeatedly by tqual.c, this saves
a lot of shared-memory searches.  And it's cheap enough that it shouldn't
hurt noticeably when it doesn't help.
Concept and patch by Simon, some minor tweaking and comment-cleanup by Tom.

> 	o Consider normalizing fractions in postgresql.conf, perhaps
> 	  using '%'
>
> 	  http://archives.postgresql.org/pgsql-hackers/2007-06/msg00550.php

> * Consider sorting writes during checkpoint
>
>   http://archives.postgresql.org/pgsql-hackers/2007-06/msg00541.php

>
> * Prefix command-line utilities like createuser with 'pg_'
>
>   http://archives.postgresql.org/pgsql-hackers/2007-06/msg00025.php

>
> * Change memory allocation for multi-byte functions so memory is
>   allocated inside conversion functions
>
>   Currently we preallocate memory based on worst-case usage.

* Consider increasing the number of default statistics target, and
  reduce statistics target overhead

  Also consider having a larger statistics target for indexed columns
  and expression indexes
<
>   http://archives.postgresql.org/pgsql-general/2007-06/msg00542.php

* Consider increasing the number of default statistics target, and
  reduce statistics target overhead

  Also consider having a larger statistics target for indexed columns
  and expression indexes
>   http://archives.postgresql.org/pgsql-general/2007-05/msg01228.php
>