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.

size_t arguments, the emitted scanner actually prototypes them with
type yy_size_t, which is sometimes not the same thing depending on
flex version and platform.  Easiest fix seems to be to use yy_size_t.
Per buildfarm results.

of features added to flex and bison since this code was originally written.
This change doesn't in itself offer any new capability, but it's needed
infrastructure for planned improvements in plpgsql.

Another feature now available in flex is the ability to make it use palloc
instead of malloc, so do that to avoid possible memory leaks.  (We should
at some point change the other lexers likewise, but this commit doesn't
touch them.)

update documentation accordingly.  This is required in order to have support
for a reentrant scanner.  I'm committing this bit separately in order to have
an easy reference if we later decide to make the minimum something different
(like 2.5.33).

into a header file that plpgsql's scan.l can see broke the previous
kluge.  Per buildfarm results.

distinction between the external API (parser.h) and declarations that only
need to be visible within the raw parser code (gramparse.h, which now is only
included by parser.c, gram.y, scan.l, and keywords.c).  This is in preparation
for the upcoming change to a reentrant lexer, which will require referencing
YYSTYPE in the declarations of base_yylex and filtered_base_yylex, hence
gram.h will have to be included by gramparse.h.  We don't want any more files
than absolutely necessary to depend on gram.h, so some cleanup is called for.

meant or the reference to a standard was unnecessary.

RelOptInfo targetlist.  It used to be that the only possibility other than
a Var was a RowExpr representing a whole-row child Var, but as of 8.4's
expanded ability to flatten appendrel members, we can get arbitrary expressions
in there.  Use the expression's type info and get_typavgwidth() to produce
an at-least-marginally-sane result.  Note that get_typavgwidth()'s fallback
estimate (32 bytes) is the same as what was here before, so there will be
no behavioral change for RowExprs.  Noted while looking at recent gripe
about constant quals pushed down to FunctionScan appendrel members ...
not only were we failing to recognize the constant qual, we were getting
the width estimate wrong :-(

last pair of parameter name/value strings, even when there are MAXPARAMS
of them.  Aboriginal bug in contrib/xml2, noted while studying bug #4912
(though I'm not sure whether there's something else involved in that
report).

This might be thought a security issue, since it's a potential backend
crash; but considering that untrustworthy users shouldn't be allowed
to get their hands on xslt_process() anyway, it's probably not worth
getting excited about.

LC_CTYPE settings to children via BackendParameters.  Per discussion,
the postmaster is now just using system defaults anyway, so we might as
well save a few cycles during backend startup.

Otherwise, the LC_CTYPE/COLLATE setting gets reverted when using plperl, which
leads to incorrect query results and index corruption.

This was accidentally broken in the per-database locale patch in 8.4. Pointed
out by Andrew Gierth.

as noted by Sebastien Flaesch.  Also update the claim that we simply throw
away fields outside this set --- that got changed later to only discard
less-significant fields.

exit code.

For servers older than 8.3, sort display of child tables by relname instead
of oid::regclass::text, because the cast from regclass to text did not work
back then.  The older display may be slightly worse when different schemas
are involved, but that should be rare enough.

more pg_catalog. qualifications.

This was an oversight in the recent patch.  Found by Tom Lane.

For character types with typmod, character_octet_length columns in the
information schema now show the maximum character length times the
maximum length of a character in the server encoding, instead of some
huge value as before.

Safely schema-qualify the pg_get_indexdef call, make the query a bit
prettier in -E mode, remove useless join to pg_index, make it more obvious
that the header[] array is not overrun.

timestamp_trunc, timestamptz_trunc, and interval_trunc().  This change
only affects the float-datetime case; the integer-datetime case already
behaved like truncation instead of rounding.  Per gripe from Mario Splivalo.

This is a pre-existing issue but I'm choosing not to backpatch, because
it's such a corner case and there have not been prior complaints.  The
issue is largely moot anyway given the trend towards integer datetimes.

In what seems like an oversight, we used to treat 'TH' the same as lowercase
'th', but only with HH/HH12.

substituting a child rel's output expressions into the appendrel's restriction
clauses yields a pseudoconstant restriction.  We might be able to skip scanning
that child rel entirely (if we get constant FALSE), or generate a one-time
filter.  8.3 more or less accidentally generated plans that weren't completely
stupid in these cases, but that was only because an extra recursive level of
subquery_planner() always occurred and allowed const-simplification to happen.
8.4's ability to pull up appendrel members with non-Var outputs exposes the
fact that we need to work harder here.  Per gripe from Sergey Burladyan.

This adds a column called "Definition" to the output of psql \d on an
index, which shows the full expression behind the index column.  For indexes
on plain columns, this is redundant,  but for expression indexes, this
reveals the real expression.

Author: Khee Chin <kheechin@gmail.com>

parentheses around the <query expression body> that follows a WITH clause, eg
	with cte(foo) as ( values(0) ) ((select foo from cte));
This seems to be just an oversight/thinko in gram.y.  Noted while
experimenting with bug #4902.