ISO_8859-5 <-> MULE_INTERNAL conversion tables.

This was discovered when trying to convert a string containing those characters
from ISO_8859-5 to Windows-1251, because we use MULE_INTERNAL/KOI8R as an
intermediate encoding between those two.

While the missing "Yo" was just an omission in the conversion tables, there are
a few other characters like the "Numero" sign ("No" as a single character) that
exists in all the other cyrillic encodings (win1251, ISO_8859-5 and cp866), but
not in KOI8R. Added comments about that.

Patch by Sergey Burladyan. Back-patch to 7.4.

is redundant because autovacuum now always analyzes a single table per
transaction.

case where there is a match to the pattern overall but the user has specified
a parenthesized subexpression and that subexpression hasn't got a match.
An example is substring('foo' from 'foo(bar)?').  This should return NULL,
since (bar) isn't matched, but it was mistakenly returning the whole-pattern
match instead (ie, 'foo').  Per bug #4044 from Rui Martins.

This has been broken since the beginning; patch in all supported versions.
The old behavior was sufficiently inconsistent that it's impossible to believe
anyone is depending on it.

except that lob's oid can be specified.

Change Copyright owner from mine to PostgreSQL Global Development Group
Fix minor message typo

* Experiment with multi-threaded backend better I/O utilization

  This would allow a single query to make use of multiple I/O channels
  simultaneously.  One idea is to create a background reader that can
  pre-fetch sequential and index scan pages needed by other backends.
  This could be expanded to allow concurrent reads from multiple devices
  in a partitioned table.

* Experiment with multi-threaded backend better CPU utilization

  This would allow several CPUs to be used for a single query, such as
  for sorting or query execution.

* Speed WAL recovery by allowing more than one page to be prefetched

  This should be done utilizing the same infrastructure used for
  prefetching in general to avoid introducing complex error-prone code
  in WAL replay.

are declared to return set, and consist of just a single SELECT.  We
can replace the FROM-item with a sub-SELECT and then optimize much as
if we were dealing with a view.  Patch from Richard Rowell, cleaned up
by me.

>
> * Consider not storing a NULL bitmap on disk if all the NULLs are
>   trailing
>
>   http://archives.postgresql.org/pgsql-hackers/2007-12/msg00624.php
>   http://archives.postgresql.org/pgsql-patches/2007-12/msg00109.php
>

errors in any commands, including in various clean targets that have so far
been handled inconsistently.  make -i is available to ignore all errors in
a consistent and official way.

on developer.postgresql.org is going away.

        o Allow UPDATE tab SET ROW (col, ...) = (SELECT...)

> 	  http://archives.postgresql.org/pgsql-patches/2007-04/msg00315.php
> 	  http://archives.postgresql.org/pgsql-patches/2008-03/msg00237.php

* Speed WAL recovery by allowing more than one page to be prefetched

  This involves having a separate process that can be told which pages
  the recovery process will need in the near future.

>   http://archives.postgresql.org/pgsql-general/2007-12/msg00683.php
>   http://archives.postgresql.org/pgsql-hackers/2007-12/msg00497.php
<

during a bitmap index scan.  This cannot affect the query results
(since we're just dumping the TIDs into a bitmap) but it might offer
some advantage in locality of access to the index.  Per Greg Stark.

> 	o Recreate pg_xlog/archive_status/ if it doesn't exist after
> 	  restoring from a PITR backup
>
> 	  http://archives.postgresql.org/pgsql-hackers/2007-12/msg00487.php

value for a precision is negative, act as though precision weren't
specified at all, that is the whole .* part of the format spec should
be ignored.  Our previous coding took it as .0 which is certainly
wrong.  Per report from Kris Jurka and local testing.

Possibly this should be back-patched, but it would be good to get
some more testing first; in any case there are no known cases where
there's really a problem on the backend side.

>
> * Consider Cartesian joins when both relations are needed to form an
>   indexscan qualification for a third relation
>
>   http://archives.postgresql.org/pgsql-performance/2007-12/msg00090.php

        o Allow COPY to report error lines and continue

          This requires the use of a savepoint before each COPY line is
          processed, with ROLLBACK on COPY failure.
> 	  http://archives.postgresql.org/pgsql-hackers/2007-12/msg00572.php

>
> * Allow SSL key file permission checks to be optionally disabled when
>   sharing SSL keys with other applications
>
>   http://archives.postgresql.org/pgsql-bugs/2007-12/msg00069.php

>
> * Reduce BIT data type overhead using short varlena headers
>
>   http://archives.postgresql.org/pgsql-general/2007-12/msg00273.php

> * Reduce file system activity overhead of statistics file pgstat.stat
>
>   http://archives.postgresql.org/pgsql-general/2007-12/msg00106.php
>

> * Consider if CommandCounterIncrement() can avoid its
>   AcceptInvalidationMessages() call
>
>   http://archives.postgresql.org/pgsql-committers/2007-11/msg00585.php

* Add SQL:2003 WITH RECURSIVE (hierarchical) queries to SELECT

>   http://archives.postgresql.org/pgsql-hackers/2007-11/msg01334.php

>
> 	o Remove pre-7.3 pg_dump code that assumes pg_depend does not exit

* Improve text search error messages

>   http://archives.postgresql.org/pgsql-hackers/2007-11/msg01146.php

> * Improve text search error messages
>
>   http://archives.postgresql.org/pgsql-hackers/2007-10/msg00966.php
>
>
> * Fix /contrib/ltree operator
>
>   http://archives.postgresql.org/pgsql-bugs/2007-11/msg00044.php

>
> 	o Fix server restart problem when the server was shutdown during
> 	  a PITR backup
>
> 	  http://archives.postgresql.org/pgsql-hackers/2007-11/msg00800.php
>

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

>   http://archives.postgresql.org/pgsql-hackers/2008-01/msg01066.php

support DTrace in the future.

Switch from using DTRACE_PROBEn macros to the dynamically generated macros.
Use "dtrace -h" to create a header file that contains the dynamically
generated macros to be used in the source code instead of the DTRACE_PROBEn
macros.  A dummy header file is generated for builds without DTrace support.

Author: Robert Lor <Robert.Lor@sun.com>

changed in case a new file got added.