< * Add MERGE command that does UPDATE/DELETE, or on failure, INSERT (rules,
<   triggers?)
> * Add SQL-standard MERGE command, typically used to merge two tables
>
>   This is similar to UPDATE, then for unmatched rows, INSERT.
>   Whether concurrent access allows modifications which could cause
>   row loss is implementation independent.
>
> * Add REPLACE or UPSERT command that does UPDATE, or on failure, INSERT

< #A hyphen, "-", marks changes that will appear in the upcoming 8.1 release.#
> #A hyphen, "-", marks changes that will appear in the upcoming 8.2 release.#

< * Remove Win32 rename/unlink looping if unnecessary

and IFNULL.

Backpatch to 8.1.X.

> * Allow COMMENT ON to accept an expression rather than just a string

<
> 	o Add -f to pg_dumpall

> 	o -Allow NULLs in arrays

>
> * Add estimated_count(*) to return an estimate of COUNT(*)
>
>   This would use the planner ANALYZE statistatics to return an estimated
>   count.

 DROP DATABASE IF EXISTS variant

process of dropping roles by dropping objects owned by them and privileges
granted to them, or giving the owned objects to someone else, through the
use of the data stored in the new pg_shdepend catalog.

Some refactoring of the GRANT/REVOKE code was needed, as well as ALTER OWNER
code.  Further cleanup of code duplication in the GRANT code seems necessary.

Implemented by me after an idea from Tom Lane, who also provided various kind
of implementation advice.

Regression tests pass.  Some tests for the new functionality are also added,
as well as rudimentary documentation.

not only the array contents, before claiming two arrays are equal.
Per recent discussion.

DROP objecttype IF EXISTS for the following objects:
  table view index sequence schema type domain conversion

the array (for array_push) or higher-dimensional array (for array_cat)
rather than decrementing it as before.  This avoids generating lower
bounds other than one for any array operation within the SQL spec.  Per
recent discussion.
Interestingly, this seems to have been the original behavior, because
while updating the docs I noticed that a large fraction of relevant
examples were *wrong* for the old behavior and are now right.  Is it
worth correcting this in the back-branch docs?

J.Kuwamura

functionality, but I still need to make another pass looking at places
that incidentally use arrays (such as ACL manipulation) to make sure they
are null-safe.  Contrib needs work too.
I have not changed the behaviors that are still under discussion about
array comparison and what to do with lower bounds.

<   so duplicate checking can be easily performed.
>   so duplicate checking can be easily performed.  It is possible to
>   do it without a unique index if we require the user to LOCK the table
>   before the MERGE.

< * Add a libpq function to support Parse/DescribeStatement capability
< * Add PQescapeIdentifier() to libpq
< * Prevent PQfnumber() from lowercasing unquoted the column name
<
<   PQfnumber() should never have been doing lowercasing, but historically
<   it has so we need a way to prevent it
<
648a642,661
>
>
> libpq
>
> 	o Add a function to support Parse/DescribeStatement capability
> 	o Add PQescapeIdentifier()
> 	o Prevent PQfnumber() from lowercasing unquoted the column name
>
> 	  PQfnumber() should never have been doing lowercasing, but
> 	  historically it has so we need a way to prevent it
>
> 	o Allow query results to be automatically batched to the client
>
> 	  Currently, all query results are transfered to the libpq
> 	  client before libpq makes the results available to the
> 	  application.  This feature would allow the application to make
> 	  use of the first result rows while the rest are transfered, or
> 	  held on the server waiting for them to be requested by libpq.
> 	  One complexity is that a query like SELECT 1/col could error
> 	  out mid-way through the result set.

>
>   To implement this cleanly requires that the table have a unique index
>   so duplicate checking can be easily performed.
>

features.

Tag everything for 8.1.0 ... Finally, a relesae on scheduale!!