> * Allow sequential scans to take advantage of other concurrent
>   sequentiqal scans, also called "Synchronised Scanning"

<         o Disallow encodings like UTF8 which PostgreSQL supports
<           but the operating system does not (already disallowed by
< 	  pginstaller)
>         o Add support for Unicode
< 	  To fix UTF8, the data needs to be converted to UTF16 and then
< 	  the Win32 wcscoll() can be used, and perhaps other functions
> 	  To fix this, the data needs to be converted to/from UTF16/UTF8
>           so the Win32 wcscoll() can be used, and perhaps other functions
< 	  locales but provides no ordering.
<
> 	  locales but provides no ordering or character set classes.

bytes/character for each encoding.

if it finds a pg_rewrite entry for which there is no pg_class entry.
Per report from Andrew Slobodyanyk.

Roland Volkmann

> * -Cache last known per-tuple offsets to speed long tuple access

output mode.  This was already stated in other places in the psql
reference page, but not here.

a tuple are being accessed via ExecEvalVar and the attcacheoff shortcut
isn't usable (due to nulls and/or varlena columns).  To do this, cache
Datums extracted from a tuple in the associated TupleTableSlot.
Also some code cleanup in and around the TupleTable handling.
Atsushi Ogawa with some kibitzing by Tom Lane.

> * Support triggers on columns (Greg Sabino Mullane)

whether or not it is a security definer. Changing a function's strictness
is required by SQL2003, and the other capabilities make sense. Also, allow
an optional RESTRICT noise word to be specified, for SQL conformance.

Some trivial regression tests added and the documentation has been
updated.

of postgres.h.

client aplications so 7.4.X releases can be installed on the same
machine as 8.0.X.

no longer include OIDs, unless WITH OIDS is specified or the
default_with_oids configuration parameter is enabled. Update the docs
accordingly.

Remove warning about pre-7.2 LATIN5 usage.

Add a few encodings that were not documented.

database's datallowconn and datfrozenxid to the current transaction ID
instead of copying the source database's values.  This is OK because we
assume the source DB contains no normal transaction IDs whatsoever.
This keeps VACUUM from immediately starting to complain about unvacuumed
databases in the situation where we are more than 2 billion transactions
out from the XID stamp of template0.  Per discussion with Milen Radev
(although his complaint turned out to be due to something else, but the
problem is real anyway).