There are numerous methods by which a Perl or Tcl function can subvert
the behavior of another such function executed later; for example, by
redefining standard functions or operators called by the target function.
If the target function is SECURITY DEFINER, or is called by such a
function, this means that any ordinary SQL user with Perl or Tcl language
usage rights can do essentially anything with the privileges of the target
function's owner.

To close this security hole, create a separate Perl or Tcl interpreter for
each SQL userid under which plperl or pltcl functions are executed within
a session.  However, all plperlu or pltclu functions run within a session
still share a single interpreter, since they all execute at the trust
level of a database superuser anyway.

Note: this change results in a functionality loss when libperl has been
built without the "multiplicity" option: it's no longer possible to call
plperl functions under different userids in one session, since such a
libperl can't support multiple interpreters in one process.  However, such
a libperl already failed to support concurrent use of plperl and plperlu,
so it's likely that few people use such versions with Postgres.

Security: CVE-2010-3433

Erik Rijkers

8.0.26, and 7.4.30.

Satoshi Nagayasu

from Tom.

rather than atol().

Per report from Brian Hirt

resource leak.  Of course, any such failure aborts pg_upgrade, but might
as well be clean about it.

Per patch from Grzegorz Ja?kiewicz.

Need a "return false" to prevent tests from continuing after we've moved
the "query" pointer.  As it stood, it'd accept "DROP DISCARD ALL" as a
match.

directory.

Per report from Harald Armin Massa.

Per report from Harald Armin Massa

The point of a PlaceHolderVar is to allow a non-strict expression to be
evaluated below an outer join, after which its value bubbles up like a Var
and can be forced to NULL when the outer join's semantics require that.
However, there was a serious design oversight in that, namely that we
didn't ensure that there was actually a correct place in the plan tree
to evaluate the placeholder :-(.  It may be necessary to delay evaluation
of an outer join to ensure that a placeholder that should be evaluated
below the join can be evaluated there.  Per recent bug report from Kirill
Simonov.

Back-patch to 8.4 where the PlaceHolderVar mechanism was introduced.

title, per suggestion from Ian Barwick.

Report by Shigeru Hanada.

We allowes DISCARD PLANS and TEMP in a transaction.

Backpatch to 8.3.

Reported by Sergey Burladyan.

This is intended as infrastructure to support integration with label-based
mandatory access control systems such as SE-Linux. Further changes (mostly
hooks) will be needed, but this is a big chunk of it.

KaiGai Kohei and Robert Haas

Devrim GÜNDÜZ

1. Resurrect the behavior where old commits on master will have Branch:
labels for branches sprouted after the commit was made.  I'm still
dubious about this mode, but if you want it, say --post-date or -p.

2. Annotate the Branch: labels with the release or branch in which the
commit was publicly released.  For example, on a release branch you could
see
Branch: REL8_3_STABLE Release: REL8_3_2 [92c3a8004] 2008-03-29 00:15:37 +0000
showing that the fix was released in 8.3.2.  Commits on master will
usually instead have notes like
Branch: master Release: REL8_4_BR [6fc9d427] 2008-03-29 00:15:28 +0000
showing that this commit is ancestral to release branches 8.4 and later.
If no Release: marker appears, the commit hasn't yet made it into any
release.

3. Add support for release branches older than 7.4.

4. The implementation is improved by running git log on each branch only
back to where the branch sprouts from master.  This saves a good deal
of time (about 50% of the runtime when generating the complete history).
We generate the post-date-mode tags via a direct understanding that
they should be applied to master commits made before the branch sprouted,
rather than backing into them via matching (which isn't any too
reliable when people used identical log messages for successive commits).

Like with tables, this also requires allowing the existence of
composite types with zero attributes.

reviewed by KaiGai Kohei

1. Don't assume there's only one candidate match; check them all and use the
one with the closest timestamp.  Avoids funny output when someone makes
several successive commits with the same log message, as certain people
have been known to do.

2. When the same commit (with the same SHA1) is reachable from multiple
branch tips, don't report it for all the branches; instead report it only
for the first such branch.  Given our development practices, this case
arises only for commits that occurred before a given branch split off from
master.  The original coding blamed old commits on *all* the branches,
which isn't terribly useful; the new coding blames such a commit only on
master.

1. Don't forget the last (oldest) commit on the oldest branch.

2. When considering which commit to print next, if two alternatives have
the same "distortion" score (which is actually the normal case, since
generally the "distortion" is 0), then choose the later timestamp to
print first.  I don't know where Robert got the idea to ignore timestamps
and sort by branch age, but it wasn't a good idea: the resulting ordering
of commits was just plain bizarre anywhere that some branches had many
fewer commits than others, which is the typical situation for us.

Avoid depending on Date::Calc, which isn't in a basic Perl installation,
when we can equally well use Time::Local which is.  Also fix the parsing
of timestamps to take heed of the timezone.  (It looks like cvs2git emitted
all commit timestamps with zone GMT, so this refinement might've looked
unnecessary when looking at converted data; but it's needed now.)

Fix parsing of message bodies so that blank lines that may or may not get
emitted by "git log" aren't confused with real data.  This avoids strange
formatting of the oldest commit on a branch.

Check child-process exit status, so that we actually notice if "git log"
fails, and so that we don't accumulate zombie children.

The previous coding would decide that join removal was unsafe upon finding
a PlaceHolderVar that needed to be evaluated at the inner rel and then used
above the join.  However, this fails to cover the case of PlaceHolderVars
that refer to both the inner rel and some other rels.  Per bug report from
Andrus.

Command synopses using <cmdsynopsis> with multiple variants previously used
<sbr> to break lines between variants.  The new man page toolchain introduced
in 9.0 makes a mess out of that, and that markup was probably wrong all along,
because <sbr> is supposed to break lines within a synopsis, not between them.
So fix that by using multiple <cmdsynopsis> elements inside <refsynopsisdiv>.

backpatched to 9.0

Fix overly-enthusiastic ignores, as identified by
git ls-files -i --exclude-standard

them after the fact.  This is a more elegant fix for bug #5595.

Kevin Grittner

Windows is not necessarily 32-bit, any more.

As suggested by Mike Toews.

This was broken in 9.0 by careless addition of an early-exit path.
Bug report and diagnosis by Jeff Davis.

hasn't been set.

The only known case where this can happen is when show_session_authorization
is invoked in an autovacuum process, which is possible if an index function
calls it, as for example in bug #5669 from Andrew Geery.  We could perhaps
try to return a sensible value, such as the name of the cluster-owning
superuser; but that seems like much more trouble than the case is worth,
and in any case it could create new possible failure modes.  Simply
returning an empty string seems like the most appropriate fix.

Back-patch to all supported versions, even those before autovacuum, just
in case there's another way to provoke this crash.

In some situations the original coding led to corrupting the child AppendRel's
subpaths list, effectively adding other members of the parent's list to it.
This was usually masked because we never made any further use of the child's
list, but given the right combination of circumstances, we could do so.  The
visible symptom would be a relation getting scanned twice, as in bug #5673
from David Schmitt.

Backpatch to 8.2, which is as far back as the risky coding appears.  The
example submitted by David only fails in 8.4 and later, but I'm not convinced
that there aren't any even-more-obscure cases where 8.2 and 8.3 would fail.

We can't actually print the parent RelOptInfo in toto, because that would
lead to infinite recursion.  But it's safe enough to reach into the parent
and print its identifying relids, and that makes it a whole lot easier
to figure out what a Path represents.  Should have done this years ago.