The printablePredicate of a static PartitionSelector node contains Var nodes
with varno=INNER. That's bogus, because the PartitionSelector node doesn't
actually have any child nodes, but works at execution time because the
printablePredicate is not only used by EXPLAIN. In most cases, it still
worked, because most Var nodes carry a varnoold field, which is used by
EXPLAIN for the lookup, but there was one case of "bogus varno" error even
memorized in the expected output of the regression suite. (PostgreSQL 8.3
changed the way EXPLAIN resolves the printable name so that varnoold no
longer saves the bacon, and you would get a lot more of those errors)

To fix, teach the EXPLAIN of a Sequence node to also reach into the
static PartitionSelector node, and print the printablePredicate as if that
qual was part of the Sequence node directly.

The user-visible effect of this is that the static Partition Selector
expression now appears in EXPLAIN output as a direct attribute of the
Sequence node, not as a separate child node. Also, if a static Partition
Selector doesn't have a "printablePredicate", i.e. it doesn't actually
do any selection, it's not printed at all.

Include a map from sliceIndex to gang_id in the dispatched string,
and remove the localSlice field, hence QE should get the localSlice
from the map now. By this way, we avoid duplicating and modifying
the dispatch text string slice by slice, and each QE of a sliced
dispatch would get same contents now.

The extra space cost is sizeof(int) * SliceNumber bytes, and the extra
computing cost is iterating the SliceNumber-size array. Compared with
memcpy of text string for each slice in previous implementation, this
way is much cheaper, because SliceNumber is much smaller than the size
of dispatch text string. Also, since SliceNumber is so small, we just
use an array for the map instead of a hash table.

Also, clean up some dead code in dispatcher, including:
(1) Remove primary_gang_id field of Slice struct and DispatchCommandDtxProtocolParms
struct, since dispatch agent is deprecated now;
(2) Remove redundant logic in cdbdisp_dispatchX;
(3) Clean up buildGpDtxProtocolCommand;

This reverts much of the changes vs. upstream, related to temp schema
creation. Instead of using the normal CREATE SCHEMA processing to also
create the temporary schema, let InitTempTableNameSpace() to do that
like in the upstream. But in addition to creating the the temp schema
locally, it dispatches a special CreateSchemaStmt command to the
executor nodes, which instructs the executor nodes to also call
InitTempTableNameSpace().

We had later added code that allows "DEFAULT NULL", by doing a table
rewrite. DEFAULT NULL is really the same as no default, so we might as well
do a table rewrite for that case too, and save the code needed to handle
them differently.

This is a partial backport of a larger body of work which also already have
been partially backported.

Remove the GPDB-specific "breadcrumbs" mechanism from the parser. It is
made obsolete by the upstream mechanism. We lose context information from
a few errors, which is unfortunate, but seems acceptable. Upstream doesn't
have context information for those errors either.

The backport was originally done by Daniel Gustafsson, on top of the
PostgreSQL 8.3 merge. I tweaked it to apply it to master, before the
merge.

Upstream commit:

  commit b153c092
  Author: Tom Lane <tgl@sss.pgh.pa.us>
  Date:   Mon Sep 1 20:42:46 2008 +0000

    Add a bunch of new error location reports to parse-analysis error messages.
    There are still some weak spots around JOIN USING and relation alias lists,
    but most errors reported within backend/parser/ now have locations.

The copy/out/read functions for it were wrong: a Bitmapset is not a Node,
so one should use e.g. COPY_BITMAPSET_FIELD() instead of COPY_NODE_FIELD()
for them. But since the fields are currently unused, let's just remove them.

These fields will be resurrected soon, by the PostgreSQL 8.3 merge, as they
were introduced in PostgreSQL 8.3. Then they will actually be used, too.

That includes the slice table, transientRecordTypes, and IntoClause's
oidInfo. These are transient information, created in ExecutorStart, not
something that should be cached along with the plan. transientRecordTypes
and oidInfo in particular were stored in PlannedStmt only so that they can
be conveniently dispatched to QEs along with the plan. That's not a problem
at the moment, but with the upcoming PostgreSQL 8.3 merge, we'll start
keeping the PlannedStmt struct around for many executions, so let's create
a new struct to hold that kind of information, which is transmitted from
QD to QEs along with the plan (that new struct is called QueryDispatchDesc).

When I merged the operator family patch, I missed dispatching the new DDL
commands to segments. Because of that, the segments didn't have information
about operator families. Some operator families would be greated implicitly
by CREATE OPERATOR CLASS, but you wouldn't necessarily get the same
configuration of families and classes as in the master. Things worked pretty
well despite that, because operator families and classes are used for
planning, and planning happens in the master. Nevertheless, we really should
have the operator family information in segments too, in case you run
queries in maintenance mode directly on the segments, or if you execute
functions in segments that need to execute expression that depend on them.
Also, there were no regression tests for the new DDL commands.

If you do CREATE OPERATOR, with a commutator or negator operator that
doesn't exist yet, the system creates a "shell" entry for the non-existent
operator. But those shell operators didn't get the same OID in all segments,
which could lead to strange errors later. I couldn't find a test case
demonstrating actual bugs from that, but it sure seems sketchy. Given that
we take care to synchronize the OID of the primary created operator, surely
we should do the same for all operators.

Makes merging easier, and is less code overall anyway. I don't think there
was any particular reason it was originally changed to differ from
upstream.

There is one slightly user-visible impact from this change: In a
full-database VACUUM ANALYZE command, the VACUUM and ANALYZE phases are
performed on one table, before moving to next, whereas before we performed
VACUUM on all tables first, and ANALYZE on all tables next. I couldn't
discern any reason from the code comments for that change in behaviour, so I
assume it was just coincidental.

Backport below commits from upstream:

    commit 31edbadf
    Author: Tom Lane <tgl@sss.pgh.pa.us>
    Date:   Tue Jun 5 21:31:09 2007 +0000

        Downgrade implicit casts to text to be assignment-only, except for the ones
        from the other string-category types; this eliminates a lot of surprising
        interpretations that the parser could formerly make when there was no directly
        applicable operator.

        Create a general mechanism that supports casts to and from the standard string
        types (text,varchar,bpchar) for *every* datatype, by invoking the datatype's
        I/O functions.  These new casts are assignment-only in the to-string direction,
        explicit-only in the other, and therefore should create no surprising behavior.
        Remove a bunch of thereby-obsoleted datatype-specific casting functions.

        The "general mechanism" is a new expression node type CoerceViaIO that can
        actually convert between *any* two datatypes if their external text
        representations are compatible.  This is more general than needed for the
        immediate feature, but might be useful in plpgsql or other places in future.

        This commit does nothing about the issue that applying the concatenation
        operator || to non-text types will now fail, often with strange error messages
        due to misinterpreting the operator as array concatenation.  Since it often
        (not always) worked before, we should either make it succeed or at least give
        a more user-friendly error; but details are still under debate.

        Peter Eisentraut and Tom Lane

    commit bf940763
    Author: Tom Lane <tgl@sss.pgh.pa.us>
    Date:   Tue Mar 27 23:21:12 2007 +0000

        Fix array coercion expressions to ensure that the correct volatility is
        seen by code inspecting the expression.  The best way to do this seems
        to be to drop the original representation as a function invocation, and
        instead make a special expression node type that represents applying
        the element-type coercion function to each array element.  In this way
        the element function is exposed and will be checked for volatility.
        Per report from Guillaume Smet.

Backport below commits from upstream:

    commit adac22bf
    Author: Tom Lane <tgl@sss.pgh.pa.us>
    Date:   Fri Dec 19 05:04:35 2008 +0000

        When we added the ability to have zero-element ARRAY[] constructs by adding an
        explicit cast to show the intended array type, we forgot to teach ruleutils.c
        to print out such constructs properly.  Found by noting bogus output from
        recent changes in polymorphism regression test.

    commit 30137bde6db48a8b8c1ffc736eb239bd7381f04d
    Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
    Date:   Fri Nov 13 19:48:26 2009 +0000

        A better fix for the "ARRAY[...]::domain" problem. The previous patch worked,
        but the transformed ArrayExpr claimed to have a return type of "domain",
        even though the domain constraint was only checked by the enclosing
        CoerceToDomain node. With this fix, the ArrayExpr is correctly labeled with
        the base type of the domain. Per gripe by Tom Lane.

    commit 6b0706ac
    Author: Tom Lane <tgl@sss.pgh.pa.us>
    Date:   Thu Mar 20 21:42:48 2008 +0000

        Arrange for an explicit cast applied to an ARRAY[] constructor to be applied
        directly to all the member expressions, instead of the previous implementation
        where the ARRAY[] constructor would infer a common element type and then we'd
        coerce the finished array after the fact.  This has a number of benefits,
        one being that we can allow an empty ARRAY[] construct so long as its
        element type is specified by such a cast.

Besides, this commit also adds 'location' field in array related
structures, but they are not actived yet. Thanks to Heikki's suggestion.

This saves a little bit of memory when parsing massively partitioned
CREATE TABLE statements.

Commits backported from upstream are listed below.

	commit 87f2ad13
	Author: Tom Lane <tgl@sss.pgh.pa.us>
	Date:   Sun Mar 27 12:51:04 2011 -0400

	    Fix plpgsql to release SPI plans when a function or DO block is freed.

	    This fixes the gripe I made a few months ago about DO blocks getting
	    slower with repeated use.  At least, it fixes it for the case where
	    the DO block isn't aborted by an error.  We could try running
	    plpgsql_free_function_memory() even during error exit, but that seems
	    a bit scary since it makes a lot of presumptions about the data
	    structures being in good shape.  It's probably reasonable to assume
	    that repeated failures of DO blocks isn't a performance-critical case.

	commit 42b2907d
	Author: Tom Lane <tgl@sss.pgh.pa.us>
	Date:   Sun Nov 29 03:02:27 2009 +0000

	    Add support for anonymous code blocks (DO blocks) to PL/Perl.

	    Joshua Tolley, reviewed by Brendan Jurd and Tim Bunce

	commit 9048b731
	Author: Tom Lane <tgl@sss.pgh.pa.us>
	Date:   Tue Sep 22 23:43:43 2009 +0000

	    Implement the DO statement to support execution of PL code without having
	    to create a function for it.

	    Procedural languages now have an additional entry point, namely a function
	    to execute an inline code block.  This seemed a better design than trying
	    to hide the transient-ness of the code from the PL.  As of this patch, only
	    plpgsql has an inline handler, but probably people will soon write handlers
	    for the other standard PLs.

	    In passing, remove the long-dead LANCOMPILER option of CREATE LANGUAGE.

	    Petr Jelinek

When applying motion, a merge other than normal gather motion should
be added on the top node if it has sort list, this can make sure that
tuples are still in order after gathered to QD. Only checking if top
level parsetree has sort clauses may miss the implicit order constraint
in a view

Users should use error log functionality for error handling in external tables
and during copy since it is more robust and reliable than the old error table
functionality.

Functions can be declared with parameters with default values or
expressions.  The default expressions are used as parameter value
if the parameter is not explicitly specified in a function call.
All parameters after a parameter with default value have to be
parameters with default values as well.

It allows user to invoke a UDF without setting all the parameters.
Two examples to demo its usage:

    CREATE FUNCTION dfunc1(text DEFAULT 'Hello', text DEFAULT 'World')
        RETURNS text AS $$
        SELECT $1 || ', ' || $2;
        $$ LANGUAGE SQL;
    SELECT dfunc1();  -- 'Hello, World'
    SELECT dfunc1('Hi');  -- 'Hi, World'
    SELECT dfunc1('Hi', 'Beijing');  -- 'Hi, Beijing'

    CREATE FUNCTION dfunc2(id int4, t timestamp DEFAULT now())
        RETURNS text AS $$
        SELECT 'Time for id:' || $1 || ' is ' || $2;
        $$ LANGUAGE SQL;
    SELECT dfunc2(24);  -- 'Time for id:24 is 2016-01-07 14:38'

NOTE: The default change set is ported from from PostgreSQL 8.4,
    original commits:
    '517ae403'
    '455dffbb'

User could use VARIADIC to specify parameter list when defining UDF
if they want to use variadic parameters. It is easier for user to write
only one variadic function instead of same name function with different
parameters. An example for using variadic:
create function concat(text, variadic anyarray) returns text as $$
select array_to_string($2, $1);
$$ language sql immutable strict;

select concat('%', 1, 2, 3, 4, 5);

NOTE: The variadic change set is ported from upstream of PostgreSQL:
commit 517ae403
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Thu Dec 18 18:20:35 2008 +0000

Code review for function default parameters patch.  Fix numerous problems as
per recent discussions.  In passing this also fixes a couple of bugs in
the previous variadic-parameters patch.

commit 6563e9e2
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Wed Jul 16 16:55:24 2008 +0000

Add a "provariadic" column to pg_proc to eliminate the remarkably expensive
need to deconstruct proargmodes for each pg_proc entry inspected by
FuncnameGetCandidates().  Fixes function lookup performance regression
caused by yesterday's variadic-functions patch.

In passing, make pg_proc.probin be NULL, rather than a dummy value '-',
in cases where it is not actually used for the particular type of function.
This should buy back some of the space cost of the extra column.

commit d89737d3
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Wed Jul 16 01:30:23 2008 +0000

Support "variadic" functions, which can accept a variable number of arguments
so long as all the trailing arguments are of the same (non-array) type.
The function receives them as a single array argument (which is why they
have to all be the same type).

It might be useful to extend this facility to aggregates, but this patch
doesn't do that.

This patch imposes a noticeable slowdown on function lookup --- a follow-on
patch will fix that by adding a redundant column to pg_proc.

Conflicts:
	src/backend/gpopt/gpdbwrappers.cpp

Alter partitioned table set distributed by will dispatch information
from QD to QEs, the information is not correctly coded and decoded on
both sides when:
1. reorganize = false.
2. table have index.
3. partition table have "with" option.

It was just syntax and catalogs, you couldn't actually do anything useful
with it. Remove it, so that we have less code to maintain, until it's time
to merge this stuff from upstream again when we merge with PostgreSQL 8.4.
It's probably easier to merge this back at that point than maintain this
backported version in the meanwhile. Less effort now, until we reach that
point, and once we get to the point in 8.4 that we merge this in, we'll
have all the preceding patches applied already, so it should merge quite
smoothly.

plan nodes, so that the executor does not need to get these items from
the range table at runtime.  This will avoid needing to include these
fields in the compact range table I'm expecting to make the executor use.

observe the xmloption.

Reorganize the representation of the XML option in the parse tree and the
API to make it easier to manage and understand.

Add regression tests for parsing back XML expressions.

FAMILY; and add FAMILY option to CREATE OPERATOR CLASS to allow adding a
class to a pre-existing family.  Per previous discussion.  Man, what a
tedious lot of cutting and pasting ...

which I had removed in the first cut of the EquivalenceClass rewrite to
simplify that patch a little.  But it's still important --- in a four-way
join problem mergejoinscansel() was eating about 40% of the planning time
according to gprof.  Also, improve the EquivalenceClass code to re-use
join RestrictInfos rather than generating fresh ones for each join
considered.  This saves some memory space but more importantly improves
the effectiveness of caching planning info in RestrictInfos.

representation of equivalence classes of variables.  This is an extensive
rewrite, but it brings a number of benefits:
* planner no longer fails in the presence of "incomplete" operator families
that don't offer operators for every possible combination of datatypes.
* avoid generating and then discarding redundant equality clauses.
* remove bogus assumption that derived equalities always use operators
named "=".
* mergejoins can work with a variety of sort orders (e.g., descending) now,
instead of tying each mergejoinable operator to exactly one sort order.
* better recognition of redundant sort columns.
* can make use of equalities appearing underneath an outer join.

which comparison operators to use for plan nodes involving tuple comparison
(Agg, Group, Unique, SetOp).  Formerly the executor looked up the default
equality operator for the datatype, which was really pretty shaky, since it's
possible that the data being fed to the node is sorted according to some
nondefault operator class that could have an incompatible idea of equality.
The planner knows what it has sorted by and therefore can provide the right
equality operator to use.  Also, this change moves a couple of catalog lookups
out of the executor and into the planner, which should help startup time for
pre-planned queries by some small amount.  Modify the planner to remove some
other cavalier assumptions about always being able to use the default
operators.  Also add "nulls first/last" info to the Plan node for a mergejoin
--- neither the executor nor the planner can cope yet, but at least the API is
in place.

per-column options for btree indexes.  The planner's support for this is still
pretty rudimentary; it does not yet know how to plan mergejoins with
nondefault ordering options.  The documentation is pretty rudimentary, too.
I'll work on improving that stuff later.

Note incompatible change from prior behavior: ORDER BY ... USING will now be
rejected if the operator is not a less-than or greater-than member of some
btree opclass.  This prevents less-than-sane behavior if an operator that
doesn't actually define a proper sort ordering is selected.

back-stamped for this.

about typmod representation for standard types out into type-specific
typmod I/O functions.  Teodor Sigaev, with some editorialization by
Tom Lane.

the XmlExpr code in various lists, use a representation that has some hope
of reverse-listing correctly (though it's still a de-escaping function
shy of correctness), generally try to make it look more like Postgres
coding conventions.

cases.  Operator classes now exist within "operator families".  While most
families are equivalent to a single class, related classes can be grouped
into one family to represent the fact that they are semantically compatible.
Cross-type operators are now naturally adjunct parts of a family, without
having to wedge them into a particular opclass as we had done originally.

This commit restructures the catalogs and cleans up enough of the fallout so
that everything still works at least as well as before, but most of the work
needed to actually improve the planner's behavior will come later.  Also,
there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way
to create a new family right now is to allow CREATE OPERATOR CLASS to make
one by default.  I owe some more documentation work, too.  But that can all
be done in smaller pieces once this infrastructure is in place.

representing externally-supplied values, since the APIs that carry such
values only specify type not typmod.  However, for PARAM_SUBLINK Params
it is handy to carry the typmod of the sublink's output column.  This
is a much cleaner solution for the recently reported 'could not find
pathkey item to sort' and 'failed to find unique expression in subplan
tlist' bugs than my original 8.2-compatible patch.  Besides, someday we
might want to support typmods for external parameters ...

in PITR scenarios.  We now WAL-log the replacement of old XIDs with
FrozenTransactionId, so that such replacement is guaranteed to propagate to
PITR slave databases.  Also, rather than relying on hint-bit updates to be
preserved, pg_clog is not truncated until all instances of an XID are known to
have been replaced by FrozenTransactionId.  Add new GUC variables and
pg_autovacuum columns to allow management of the freezing policy, so that
users can trade off the size of pg_clog against the amount of freezing work
done.  Revise the already-existing code that forces autovacuum of tables
approaching the wraparound point to make it more bulletproof; also, revise the
autovacuum logic so that anti-wraparound vacuuming is done per-table rather
than per-database.  initdb forced because of changes in pg_class, pg_database,
and pg_autovacuum catalogs.  Heikki Linnakangas, Simon Riggs, and Tom Lane.

Bernd Helmle

blocking concurrent writes to the table.  Greg Stark, with a little help
from Tom Lane.

by abandoning the idea that it should say SERIAL in the dump.  Instead,
dump serial sequences and column defaults just like regular ones.
Add a new backend command ALTER SEQUENCE OWNED BY to let pg_dump recreate
the sequence-to-column dependency that was formerly created "behind the
scenes" by SERIAL.  This restores SERIAL to being truly "just a macro"
consisting of component operations that can be stated explicitly in SQL.
Furthermore, the new command allows sequence ownership to be reassigned,
so that old mistakes can be cleaned up.

Also, downgrade the OWNED-BY dependency from INTERNAL to AUTO, since there
is no longer any very compelling argument why the sequence couldn't be
dropped while keeping the column.  (This forces initdb, to be sure the
right kinds of dependencies are in there.)

Along the way, add checks to prevent ALTER OWNER or SET SCHEMA on an
owned sequence; you can now only do this indirectly by changing the
owning table's owner or schema.  This is an oversight in previous
releases, but probably not worth back-patching.