The capability for changing language owners is new in 8.3, so that's how
far back this needs to be backpatched.

Per bug #4132 by Kirill Simonov.

Brendan Jurd, minor editorialization by me.

of functions.

test.  We have seen some buildfarm failures that seem to be due to this
limit being unexpectedly exceeded when the machine is under load.

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

which is a global variable not a function, and so the probe failed on machines
where the linker makes a distinction (cf. Red Hat bug #444317).  Probe for
an actual function instead.

array's subscripts.

Pavel Stehule, some editorialization by me.

them.

do CancelBackup at a sane place, fix some oversights in the state transitions,
allow only superusers to connect while we are waiting for backup mode to end.

* Allow adding/renaming/removing enumerated values to an existing
  enumerated data type
>
>   http://archives.postgresql.org/pgsql-hackers/2008-04/msg01718.php
>

> * Allow adding/renaming/removing enumerated values to an existing
>   enumerated data type

flags by separate AT_SetNotNull subcommands.  That was always ugly and
inefficient, and it's now clear that it was merely a partial workaround
for the bug just identified in ATExecAddColumn.  This is just code
beautification not a bug fix, so no back-patch.

Brendan Jurd, with some trivial additional cleanup by me.

< * Allow adding enumerated values to an existing enumerated data
> * Allow adding/removing enumerated values to an existing enumerated data

checked to see if it's been initialized to all non-nulls.  The implicit NOT
NULL constraint was not being checked during the ALTER (in fact, not even if
there was an explicit NOT NULL too), because ATExecAddColumn neglected to
set the flag needed to make the test happen.  This has been broken since
the capability was first added, in 8.0.

Brendan Jurd, per a report from Kaloyan Iliev.

> * 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.