SELECT CURRENT_TIMESTAMP;
	SELECT now();
	SELECT TIMESTAMP 'now';  -- incorrect for use with DEFAULT

more variables can be found in the libpq manual section.

Mention .pgpass in the psql manual page section dealing with connection
parameters and point to the libpq section for more details.

Backpatch to 8.0.X.

as valid input (it was previously treated as 0). This input was deprecated
in 8.0 (and a warning was emitted). Regression tests updated.

Per gripes from Mike Mascari and Bernd Heller.

that return tuples (such as EXPLAIN).  Per gripe from Michael Fuhr.
Side effect: fix an old bug that unintentionally disabled backward scans
for all SPI-created cursors.

Yutaka <tanida@sra.co.jp>.

suggestion from Rainer Brandt.

FreeBSD. From Mark Kirkwood, editorializing by Neil Conway.

Fetter and Ben Calvert.

Backpatch to 8.0.X.

column with a default expression. In that situation, we need to rewrite
the heap relation. To evaluate the new default expression, we use
ExecEvalExpr(); however, this can allocate memory in the current memory
context, and ATRewriteTable() does not switch out of the active portal's
heap memory context. The end result is a rather large memory leak (on
the order of gigabytes for a reasonably sized table).

This patch changes ATRewriteTable() to switch to the per-tuple memory
context before beginning the per-tuple loop. It also removes an explicit
heap_freetuple() in the loop, since that is no longer needed.

In an unrelated change, I noticed the code was scanning through the
attributes of the new tuple descriptor for each tuple of the old table.
I changed this to use precomputation, which should slightly speed up
the loop.

Thanks to steve@deefs.net for reporting the leak.

< *  Allow the PITR process to be debugged and data examined
> * Allow the PITR process to be debugged and data examined

the item:

< 	o Automatic failover
<
< 	  The proper solution to this will probably the use of a master/slave
< 	  replication solution like Sloney and a connection pooling tool like
< 	  pgpool.
<

"incompatibilities" section of the release notes.

there are corner cases involving dropping toasted columns in which the
previous coding would fail, too: the new version of the table might not
have any TOAST table, but we'd still propagate possibly-wide values of
dropped columns forward.

now depends on.

ReleaseAndReadBuffer during GIST index searches.  We already did this
in btree and rtree, might as well do it here too.

from LockRelease() and LockReleaseAll() into it. From Heikki Linnakangas.

database: aggregates should be dumped in the same pass as operators,
not in the same pass as functions.

This refactoring does not change any algorithms or data structures, just
remove visibility of the ARC datastructures from other source files.

two arguments.  Per suggestions from A. Ogawa.

form of CASE (eg, CASE 0 WHEN 1 THEN ...) can be constant-folded as it
was in 7.4.  Also, avoid constant-folding result expressions that are
certainly unreachable --- the former coding was a bit cavalier about this
and could generate unexpected results for all-constant CASE expressions.
Add regression test cases.  Per report from Vlad Marchenko.

      The 8.1 release will remove the <function>to_char()</> function
      for intervals.

<   all temporary tables, removal of any NOTIFYs, etc.  This could be used
<   for connection pooling.  We could also change RESET ALL to have this
<   functionality.
>   all temporary tables, removal of any NOTIFYs, cursors, prepared
>   queries(?), currval()s, etc.  This could be used for connection pooling.
>   We could also change RESET ALL to have this functionality.

	* Update inet/cidr data types with newest Bind patches

tests. Contributed by Koju Iijima, review from Neil Conway, Gavin Sherry
and Tom Lane.

Also, fix error in description of WITH CHECK OPTION clause in the CREATE
VIEW reference page: it should be "CASCADED", not "CASCADE".

command counter more than necessary. Per report from Michael Fuhr.

estimate to less than the number of values estimated for any one grouping
Var, as suggested by Manfred.  This is intuitively right, and what's
more it puts the plan choices in the subselect regression test back the
way they were before ...

initially NULL.  For 8.0 we changed the main executor to have this
behavior in an UPDATE of an array column, but plpgsql's equivalent case
was overlooked.  Per report from Sven Willenberger.

< * Change LIMIT/OFFSET to use int8
> * Change LIMIT/OFFSET and FETCH/MOVE to use int8

> * Allow GRANT/REVOKE permissions to be inherited by objects based on
>   schema permissions