> * Allow prepared transactions with temporary tables created and dropped
>   in the same transaction, and when an ON COMMIT DELETE ROWS temporary
>   table is accessed
>
>   http://archives.postgresql.org/pgsql-hackers/2008-03/msg00047.php

>
> 	o Impove COPY performance
>
> 	  http://archives.postgresql.org/pgsql-hackers/2008-02/msg00954.php

* Allow index scans to return matching index keys, not just the matching
  heap locations
>
>   http://archives.postgresql.org/pgsql-hackers/2008-04/msg01657.php
>

> * Allow index scans to return matching index keys, not just the matching
>   heap locations

<
> * Allow adding enumerated values to an existing enumerated data
>   type

< * Allow index scans to return matching index keys
<
<   http://archives.postgresql.org/pgsql-hackers/2007-03/msg01079.php

* Consider smaller indexes that record a range of values per heap page,
  rather than having one index entry for every heap row

Laurenz Albe

>   http://archives.postgresql.org/pgsql-hackers/2008-04/msg01589.php

<
> 	o Add prompt escape to display the client and server versions

>   http://archives.postgresql.org/pgsql-hackers/2008-04/msg01475.php

have pg_ctl warn about this.

Cancel running online backups (by renaming the backup_label file,
thus rendering the backup useless) when shutting down in fast mode.

Laurenz Albe

<craig@postnewspapers.com.au>.
It was my mistake, I missed limitation of number of held locks, now GIN doesn't
use continiuous locks, but still hold buffers pinned to prevent interference
with vacuum's deletion algorithm.

Backpatch is needed.

it now lives (per discussion). Leave the other FAQs alone for now.

ordinary expressions.  This probably doesn't catch every single case
where you might get "cache lookup failed for function 0" for use of a
shell operator, but it will catch most.  Per bug #4120 from Pedro Gimeno.

This patch incidentally folds make_op_expr() into its sole remaining
caller --- the alternative was to give it yet more arguments, which
didn't seem an improvement.

output is not of the same type that's needed for the IN comparison (ie,
where the parser inserted an implicit coercion above the subselect result).
We should record the coerced expression, not just a raw Var referencing
the subselect output, as the quantity that needs to be unique-ified if
we choose to implement the IN as Unique followed by a plain join.

As of 8.3 this error was causing crashes, as seen in bug #4113 from Javier
Hernandez, because the executor was being told to hash or sort the raw
subselect output column using operators appropriate to the coerced type.

In prior versions there was no crash because the executor chose the
hash or sort operators for itself based on the column type it saw.
However, that's still not really right, because what's unique for one data
type might not be unique for another.  In corner cases we could get multiple
outputs of a row that should appear only once, as demonstrated by the
regression test case included in this commit.

However, this patch doesn't apply cleanly to 8.2 or before, and the code
involved has shifted enough over time that I'm hesitant to try to back-patch.
Given the lack of complaints from the field about such corner cases, I think
the bug may not be important enough to risk breaking other things with a
back-patch.

from inside the build script.

version ones, to make it clear to users just browsing the notes
that there are a lot more changes available from whatever version
they are at than what's in the minor version release notes.

UPDATE/SHARE couldn't occur as a subquery in a query with a non-SELECT
top-level operation.  Symptoms included outright failure (as in report from
Mark Mielke) and silently neglecting to take the requested row locks.

Back-patch to 8.3, because the visible failure in the INSERT ... SELECT case
is a regression from 8.2.  I'm a bit hesitant to back-patch further given the
lack of field complaints.

measure to get the Windows buildfarm members working again.  I don't
know if it's worth exposing these as configurables, or exactly how to
do it in the MSVC build system ...

and version-1 if USE_FLOAT8_BYVAL.  This might seem a bit pointless, but the
idea is to have at least one regression test that will fail if we ever
accidentally break version-0 functions that return float8.  However, they're
already broken, or at least hopelessly unportable, in the USE_FLOAT8_BYVAL
case.

Per a recent suggestion from Greg Stark.

where Datum is 8 bytes wide.  Since this will break old-style C functions
(those still using version 0 calling convention) that have arguments or
results of these types, provide a configure option to disable it and retain
the old pass-by-reference behavior.  Likewise, provide a configure option
to disable the recently-committed float4 pass-by-value change.

Zoltan Boszormenyi, plus configurability stuff by me.

I never understood why initial authors GiST in pgsql choose so
stgrange signature for 'same' method:
bool *sameFn(Datum a, Datum b, bool* result)
instead of simple, logical
bool sameFn(Datum a, Datum b)
This change will break any existing GiST extension, so we still live with
it and will live.

to future-proof it against pass-by-value float8.

archives.  We have been using URLs for a while for new items.

conventions.

I also changed seg_in and seg_out, which was probably unnecessary, but
it can't harm.

uses of the long-deprecated float32 in contrib/seg; the definitions themselves
are still there, but no longer used.  fmgr/README updated to match.

I added a CREATE FUNCTION to account for existing seg_center() code in seg.c
too, and some tests for it and the neighbor functions.  At the same time,
remove checks for NULL which are not needed (because the functions are declared
STRICT).

I had to do some adjustments to contrib's btree_gist too.  The choices for
representation there are not ideal for changing the underlying types :-(

Original patch by Zoltan Boszormenyi, with some adjustments by me.

file; the idea is that we should clean up as much as we can, even if there's
some problem removing one file.  Make the error messages a bit less misleading,
too.  In passing, const-ify function arguments.

place to prevent reusing relation OIDs before next checkpoint, and DROP
DATABASE. First, if a database was dropped, bgwriter would still try to unlink
the files that the rmtree() call by the DROP DATABASE command has already
deleted, or is just about to delete. Second, if a database is dropped, and
another database is created with the same OID, bgwriter would in the worst
case delete a relation in the new database that happened to get the same OID
as a dropped relation in the old database.

To fix these race conditions:
- make rmtree() ignore ENOENT errors. This fixes the 1st race condition.
- make ForgetDatabaseFsyncRequests forget unlink requests as well.
- force checkpoint on in dropdb on all platforms

Since ForgetDatabaseFsyncRequests() is asynchronous, the 2nd change isn't
enough on its own to fix the problem of dropping and creating a database with
same OID, but forcing a checkpoint on DROP DATABASE makes it sufficient.

Per Tom Lane's bug report and proposal. Backpatch to 8.3.