Taro Minowa (Higepon)

a physical tuple in do_tup_output().  A virtual tuple is easier to set up
and also easier for most tuple receivers to process.  Per my comment on
Robert Haas' recent patch in this code.

of individually pfree'ing pass-by-reference transition values.  This should
be at least as fast as the prior coding, and it has the major advantage of
clearing out any working data an aggregate function may have stored in or
underneath the aggcontext.  This avoids memory leakage when an aggregate
such as array_agg() is used in GROUP BY mode.  Per report from Chris Spotts.

Back-patch to 8.4.  In principle the problem could arise in prior versions,
but since they didn't have array_agg the issue seems not critical.

for the case that the semijoin was implemented within either input by
unique-ifying its RHS before we test to see if it appears to match the current
join situation.  The previous coding would select semijoin logic in situations
where we'd already unique-ified the RHS and joined it to some unrelated
relation(s), and then came to join it to the semijoin's LHS.  That still gave
the right answer as far as the semijoin itself was concerned, but would lead
to incorrectly examining only an arbitrary one of the matchable rows from the
unrelated relation(s).  The cause of this thinko was incorrect unification of
the pre-8.4 logic for IN joins and OUTER joins --- the comparable case for
outer joins can be handled after making the match test, but that's because
there is nothing like the unique-ification escape hatch for outer joins.
Per bug #4934 from Benjamin Reed.

found by "Vesa-Matti J Kari" <vmkari@cc.helsinki.fi>

so it doesn't go through BuildTupleFromCStrings.  This is more or less a
wash for current uses, but will avoid inefficiency for planned changes to
EXPLAIN.

Robert Haas

Replace redundant PLpgSQL_dstring functionality with StringInfo.
Patch by Pavel Stehule. Review by Joe Conway.

not forced out-of-line unless that is necessary to make the row fit on a
page.  Previously, they were forced out-of-line if needed to get the row
down to the default target size (1/4th page).

Kevin Grittner

In passing, make invocations of lo_xxx functions a bit more schema-safe.

Itagaki Takahiro

It appears that, for no particularly good reason, pg_listener.h deviates from
the usual convention for declaring attribute number constants.  Normally, it's

#define Anum_{catalog-name}_{column-name}  {attribute-number}

pg_listener.h, however substitutes a different string that is similar, but not
the same as, the column name.  This change fixes that.

Author: Robert Haas <robertmhaas@gmail.com>

by using a lookup table instead of a naive shift-and-count loop.  Based on
code originally posted by Sean Eron Anderson at
http://graphics.stanford.edu/%7eseander/bithacks.html.
Greg Stark did the research and benchmarking to show that this is what
we should use.  Jeremy Kerr first noticed that this is a hotspot that
could be optimized, though we ended up not using his suggestion of
platform-specific bit-searching code.

The English FAQ has been moved to the wiki, so the translated versions should
have been removed at that point as well.

The FAQ_MINGW.html should have been removed when the platform FAQs were
integrated into the documentation (or earlier).

applied to both 8.4 and 8.5

tabs in the documentation source.

reorder a semijoin into or out of the righthand side of another semijoin,
but actually it doesn't work to reorder it into or out of the righthand
side of a left or antijoin, either.  Per bug #4906 from Mathieu Fenniak.

This was sloppy thinking on my part.  This identity does work:

	( A left join B on (Pab) ) semijoin C on (Pac)
==
	( A semijoin C on (Pac) ) left join B on (Pab)

but I failed to see that that doesn't mean this does:

	( A left join B on (Pab) ) semijoin C on (Pbc)
!=
	A left join ( B semijoin C on (Pbc) ) on (Pab)

Backpatch to 8.4.X.

The original coding was not dealing specially with this file being a symlink,
with the end result that it was not installed in VPATH builds.  Oddly enough,
the clean target does know about it ...

Error messages from PL/Python now always mention the function name in the
CONTEXT: field.  This also obsoletes the few places that tried to do the
same manually.

Regression test files are updated to work with Python 2.4-2.6.  I don't have
access to older versions right now.

column names to be found in a sequence.  Per gripe from Bruce.

foo <> false, along with its previous duties of simplifying foo = true
and foo = false.  (All of these are equivalent to just foo or NOT foo
as the case may be.)  It's not clear how often this is really useful;
but it costs almost nothing to do, and it seems some people think we
should be smart about such cases.  Per recent bug report.

sequence, even when the input "tour" doesn't lead directly to such a sequence.
The stack logic that was added in 2004 only supported cases where relations
that had to be joined to each other (due to join order restrictions) were
adjacent in the tour.  However, relying on a random search to figure that out
is tremendously inefficient in large join problems, and could even fail
completely (leading to "failed to make a valid plan" errors) if
random_init_pool ran out of patience.  It seems better to make the
tour-to-plan transformation a little bit fuzzier so that every tour can form
a legal plan, even though this means that apparently different tours will
sometimes yield the same plan.

In the same vein, get rid of the logic that knew that tours (a,b,c,d,...)
are the same as tours (b,a,c,d,...), and therefore insisted the latter
are invalid.  The chance of generating two tours that differ only in
this way isn't that high, and throwing out 50% of possible tours to
avoid such duplication seems more likely to waste valuable genetic-
refinement generations than to do anything useful.

This leaves us with no cases in which geqo_eval will deem a tour invalid,
so get rid of assorted kluges that tried to deal with such cases, in
particular the undocumented assumption that DBL_MAX is an impossible
plan cost.

This is all per testing of Robert Haas' lets-remove-the-collapse-limits
patch.  That idea has crashed and burned, at least for now, but we still
got something useful out of it.

It's possible we should back-patch this change, since the "failed to make a
valid plan" error can happen in existing releases; but I'd rather not until
it has gotten more testing.

by unique-ifying the RHS and then inner-joining to some other relation,
that is not grounds for violating the RHS of some other outer join.
Noticed while regression-testing new GEQO code, which will blindly follow
any path that join_is_legal says is legal, and then complain later if that
leads to a dead end.

I'm not certain that this can result in any visible failure in 8.4: the
mistake may always be masked by the fact that subsequent attempts to join
the rest of the RHS of the other join will fail.  But I'm not certain it
can't, either, and it's definitely not operating as intended.  So back-patch.

The added regression test depends on the new no-failures-allowed logic
that I'm about to commit in GEQO, so no point back-patching that.

memory leakage in error recovery.  We were calling FreeExprContext, and
therefore invoking ExprContextCallback callbacks, in both normal and error
exits from subtransactions.  However this isn't very safe, as shown in
recent trouble report from Frank van Vugt, in which releasing a tupledesc
refcount failed.  It's also unnecessary, since the resources that callbacks
might wish to release should be cleaned up by other error recovery mechanisms
(ie the resource owners).  We only really want FreeExprContext to release
memory attached to the exprcontext in the error-exit case.  So, add a bool
parameter to FreeExprContext to tell it not to call the callbacks.

A more general solution would be to pass the isCommit bool parameter on to
the callbacks, so they could do only safe things during error exit.  But
that would make the patch significantly more invasive and possibly break
third-party code that registers ExprContextCallback callbacks.  We might want
to do that later in HEAD, but for now I'll just do what seems reasonable to
back-patch.

that the sanity checking I added to create_mergejoin_plan() in 8.3 was a
few bricks shy of a load: the mergeclauses could reference pathkeys in a
noncanonical order such as x,y,x, not only cases like x,x,y which is all
that the code had allowed for.  The odd cases only turn up when using
redundant clauses in an outer join condition, which is why no one had
noticed before.

random number seed each time.  This is how it used to work years ago, but
we got rid of the seed reset because it was resetting the main random()
sequence and thus having undesirable effects on the rest of the system.
To fix, establish a private random number state for each execution of
geqo(), and initialize the state using the new GUC variable geqo_seed.
People who want to experiment with different random searches can do so
by changing geqo_seed, but you'll always get the same plan for the same
value of geqo_seed (if holding all other planner inputs constant, of course).

The new state is kept in PlannerInfo by adding a "void *" field reserved
for use by join_search hooks.  Most of the rather bulky code changes in
this commit are just arranging to pass PlannerInfo around to all the GEQO
functions (many of which formerly didn't receive it).

Andres Freund, with some editorialization by Tom

and extend configure to test for it properly instead of hard-wiring
an assumption that everybody but Windows has the rand48 functions.
(We do cheat to the extent of assuming that probing for erand48 will do
for the entire rand48 family.)

erand48() is unused as of this commit, but a followon patch will cause
GEQO to depend on it.

Andres Freund, additional hacking by Tom

This alters various incidental uses of C++ key words to use other similar
identifiers, so that a C++ compiler won't choke outright.  You still
(probably) need extern "C" { }; around the inclusion of backend headers.

based on a patch by Kurt Harriman <harriman@acm.org>

Also add a script cpluspluscheck to check for C++ compatibility in the
future.  As of right now, this passes without error for me.

Set up proper makefile dependencies in the documentation build rules,
especially around the HTML/index build.  The problem we've had with all
previous solutions is that we have used the same file name, such as HTML.index
or bookindex.sgml, to mean different things at different stages of the build,
and make can't distinguish that.  The solution here is that the first jade run
produces HTML.index, but does not require bookindex.sgml at all, and produces
no other html output (the latter an idea from Alvaro).  The second jade run
includes bookindex.sgml, but does not recreate HTML.index.  That way, when you
change an sgml file, jade is run twice and at the end all dependencies are
satisfied.  Omitting the html output in the first stage also makes the full
build a lot faster.

When you run one of the print format targets, only the first jade run is run,
then the print target-specific commands.  If an HTML build has completed
previously, the first jade run is skipped because the dependencies have
already been satisfied.

The draft and check targets for quick builds and syntax verification are still
there.

(Apparently, some but not all versions of Bison will warn about this.)

Changes:

Pass in the keyword lookup array instead of having it be hardwired.
(This incidentally allows elimination of some duplicate coding in ecpg.)

Re-order the token declarations in gram.y so that non-keyword tokens have
numbers that won't change when keywords are added or removed.

Add ".." and ":=" to the set of tokens recognized by scan.l.  (Since these
combinations are nowhere legal in core SQL, this does not change anything
except the precise wording of the error you get when you write this.)

RevalidateCachedPlan.  This is to avoid a "SPI_ERROR_CONNECT" failure when
the planner calls a SPI-using function and we are already inside one.
The alternative fix is to expect callers of RevalidateCachedPlan to do this,
which seems likely to result in additional hard-to-detect bugs of omission.
Per reports from Frank van Vugt and Marek Lewczuk.

Back-patch to 8.3. It's much harder to trigger the bug in 8.3, due to a
smaller set of cases in which plans can be invalidated, but it could happen.
(I think perhaps only a SI reset event could make 8.3 fail here, but that's
certainly within the realm of possibility.)

No need for VACUUM ANAYZE of newly created/populated temp table, just
use analyze.

No need to apologize for using subquery in DELETE anymore.

 - yes_or_no domain for "boolean" data
 - new columns for VIEWS view
 - slight section renumbering

the full path and version of the program being rejected.