btree;  keep mention about missing WAL logging.

Kenneth Marshall

first.

Alvaro Herrera

bit more visibility to the PGOPTIONS environment variable supported by
libpq.

Bryce Nesbitt

designations (AM/PM).  Also separate out matching of a meridian with
periods (e.g. A.M.) and with those without.

Do the same for AD/BC.

Brendan Jurd

keys when considering a semi or anti join.  This requires estimating the
selectivity of the merge qual as though it were a regular inner join condition.
To allow caching both that and the real outer-join-aware selectivity, split
RestrictInfo.this_selec into two fields.

This fixes one of the problems reported by Kevin Grittner.

has_column_privilege and has_any_column_privilege SQL functions; fix the
information_schema views that are supposed to pay attention to column
privileges; adjust pg_stats to show stats for any column you have select
privilege on; and fix COPY to allow copying a subset of columns if the user
has suitable per-column privileges for all the columns.

To improve efficiency of some of the information_schema views, extend the
has_xxx_privilege functions to allow inquiring about the OR of a set of
privileges in just one call.  This is just exposing capability that already
existed in the underlying aclcheck routines.

In passing, make the information_schema views report the owner's own
privileges as being grantable, since Postgres assumes this even when the grant
option bit is not set in the ACL.  This is a longstanding oversight.

Also, make the new has_xxx_privilege functions for foreign data objects follow
the same coding conventions used by the older ones.

Stephen Frost and Tom Lane

Andrew Chernow

statement

Pavel Stehule

the cheapest-total inner path as a new candidate while truncating the
sort key list, if it already matched the full sort key list.  This is
too much of a corner case to be worth back-patching, since it's unusual
for the cheapest total path to be sorted, and anyway no real harm is
done (except in JOIN_SEMI/ANTI cases where cost_mergejoin is a bit
broken at the moment).  But it wasn't behaving as intended, so fix it.
Noted while examining a test case from Kevin Grittner.  This error doesn't
explain his issue, but it does explain why "set enable_seqscan = off"
seemed to reproduce it for me.

behavior of concurrent commands in cases where rows are being added and
removed from matching query criteria.

Minor word-smithing.

unnecessary thread address output parameter, to make this code look more
like that in pg_restore.

per gripe from David Wheeler that this was mentioned nowhere.
In passing, editorialize a bit on the description of the SQL:2008
equivalent syntax.

in the string, not just at the start.  Per bug #4629 from Martin Blazek.

Back-patch to 8.2; prior versions don't have the problem, at least not in
the reported case, because they don't try to recognize INTO in non-SELECT
statements.  (IOW, this is really fallout from the RETURNING patch.)

post-data step is run in a separate worker child (a thread on Windows, a child
process elsewhere) up to the concurrent number specified by the new pg_restore
command-line --multi-thread | -m switch.

Andrew Dunstan, with some editing by Tom Lane.

qualifier, and add support for this in pg_dump.

This allows TOAST tables to have user-defined fillfactor, and will also
enable us to move the autovacuum parameters to reloptions without taking
away the possibility of setting values for TOAST tables.

Alvaro.

It's missing in older versions too, but it doesn't seem worth
back-porting. All negative are just harmlessly treated as "no limit", and
tightening the check might even brake an application that relies on it.

as the preferred spelling of that zone name, corrects historical DST
information for Switzerland and Cuba.

encoding conversion functions.  These are not can't-happen cases because
it's possible to create a conversion with the wrong conversion function
for the specified encoding pair.  That would lead to an Assert crash in
an Assert-enabled build, or incorrect conversion otherwise, neither of
which is desirable.  This would be a DOS issue if production databases
were customarily built with asserts enabled, but fortunately that's not so.
Per an observation by Heikki.

Back-patch to all supported branches.