ALTER TABLE .. VALIDATE CONSTRAINT previously
gave incorrect details about lock levels and
therefore incomplete reasons to use the option.

Initial bug report and fix from Marko Tiikkaja
Reworded by me to include comments by Kevin Grittner

Patch by me, reviewed by Tatsuo Ishii.

lo_read()/lo_write() in libpq to avoid confusion.

Per discussion, this restriction isn't needed for any real security reason,
and it seems to confuse people more often than it helps them.  It could
also result in some database states being unrestorable.  So just drop it.

Back-patch to 9.0, where ALTER DEFAULT PRIVILEGES was introduced.

It claimed the value was always zero; it is really always -1.

Per report from Hari Babu

backpatch 734fbbd1 to 8.4

Swap the order of a couple of phrases to clarify what the adjective
"subsequent" applies to.

Joshua Tolley

Backpatch to 9.2.

Karl O. Pinc

Tomas Vondra

The documentation for ALTER TYPE .. RENAME claimed to support a
RESTRICT/CASCADE option at the 'type' level, which wasn't implemented
and doesn't make a whole lot of sense to begin with.  What is supported,
and previously undocumented, is

ALTER TYPE .. RENAME ATTRIBUTE .. RESTRICT/CASCADE.

I've updated the documentation and back-patched this to 9.1 where it was
first introduced.

The 9.2 patch that added argument name support in SQL-language functions
missed updating a parenthetical comment about that in the CREATE FUNCTION
reference page.  Noted by Erwin Brandstetter.

Restore 4-byte designation for docs.  Fix 9.3 doc query to properly pad
to four digits.

Backpatch to all active branches

Per suggestions from Ian Lawrence Barwick

Backpatch to 9.2.

Report from Ian Lawrence Barwick

LANGUAGE 'plpgsql' no longer works.  The single quotes need to be
removed.

Erwin Brandstetter

Remove references to "one click", as we're not supposed to call
them that anymore.

There's been some confusion expressed about this point, so clarify.
Extended version of a patch by David Wheeler.

Security: CVE-2013-1899, CVE-2013-1901

I changed this in commit fd15dba5, but
missed the fact that the SGML documentation of the function specified
exactly what it did.  Well, one of the two places where it's specified
documented that --- probably I looked at the other place and thought
nothing needed to be done.  Sync the two places where encode() and
decode() are described.

Doing that results in a broken index entry in PDF output.  We had only
a few like that, which is probably why nobody noticed before.
Standardize on putting the <term> first.

Josh Kupershmidt

The docs showed that early-January dates can be considered part of the
previous year for week-counting purposes, but failed to say explicitly
that late-December dates can also be considered part of the next year.
Fix that, and add a cross-reference to the "isoyear" field.  Per bug
#7967 from Pawel Kobylak.

Josh Kupershmidt

It is obviously no longer true.

Backpatch to release 9.2

Brar Piening and Noah Misch, reviewed by Craig Ringer.

This function was misdeclared to take cstring when it should take internal.
This at least allows crashing the server, and in principle an attacker
might be able to use the function to examine the contents of server memory.

The correct fix is to adjust the system catalog contents (and fix the
regression tests that should have caught this but failed to).  However,
asking users to correct the catalog contents in existing installations
is a pain, so as a band-aid fix for the back branches, install a check
in enum_recv() to make it throw error if called with a cstring argument.
We will later revert this in HEAD in favor of correcting the catalogs.

Our thanks to Sumit Soni (via Secunia SVCRP) for reporting this issue.

Security: CVE-2013-0255

Revert commit 84725aa5

Following bug analysis of #7819 by Tom Lane

Mention it might be necessary to modify postgresql.conf in the new
cluster to match the old cluster.

Backpatch to 9.2.

Suggested by user.

My "fix" for bugs #7578 and #6116 on DROP OWNED at fe3b5eb0 not only
misstated that it applied to REASSIGN OWNED (which it did not affect),
but it also failed to fix the problems fully, because I didn't test the
case of owned shared objects.  Thus I created a new bug, reported by
Thomas Kellerer as #7748, which would cause DROP OWNED to fail with a
not-for-user-consumption error message.  The code would attempt to drop
the database, which not only fails to work because the underlying code
does not support that, but is a pretty dangerous and undesirable thing
to be doing as well.

This patch fixes that bug by having DROP OWNED only attempt to process
shared objects when grants on them are found, ignoring ownership.

Backpatch to 8.3, which is as far as the previous bug was backpatched.

Backpatch to 9.2

per Tom Lane

Backpatch to 9.2.

Patch from Alan B

Backpatch to 9.2

Shigeru HANADA

Noted by Joe Van Dyk

Backpatch to 9.2.

Patch from Kohei KaiGai

Since 9.0, the count parameter has only limited the number of tuples
actually returned by the executor.  It doesn't affect the behavior of
INSERT/UPDATE/DELETE unless RETURNING is specified, because without
RETURNING, the ModifyTable plan node doesn't return control to execMain.c
for each tuple.  And we only check the limit at the top level.

While this behavioral change was unintentional at the time, discussion of
bug #6572 led us to the conclusion that we prefer the new behavior anyway,
and so we should just adjust the docs to match rather than change the code.
Accordingly, do that.  Back-patch as far as 9.0 so that the docs match the
code in each branch.

Leading white space before the "http:" is apparently treated as a
relative link at least by some browsers.

Josh Kupershmidt