Signed-off-by: NGeorge Caragea <gcaragea@pivotal.io>

If log_min_messages = 'debug5', we call the text output function for
everything that's serialized to be sent from QD to QEs. I added a new
node type, QueryDispatchDesc, in commit 41478b89, but I only gave it
the "fast" output function, not the text version. That produced a
warning about missing output function, with log_min_messages='debug5'.

This fixes the failure of qp_executor test, reported by Omar Arap.

The readRangeTblEntry() function was missing the line for 'pseudocols'
field. I'm surprised the function worked at all, I thought the read
functions don't work if there are any extra fields. Maybe they're more
forgiving if it's last field that's missing. In any case, seems like an
oversight. It doesn't matter in practice, as the pseudocols field is only
used during planning, and we don't serialize nodes at that stage. Rule
definitions are serialized before planning, and for the transfer between
QD and QEs, we use the 'fast' versions of these functions.

In the 'fast' version, the 'pseudocols' is missing from both the out
function and the read function. That seems intentional, so add a comment
about it.

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.

The multiset_5 function returns a "SET OF example", but the 'a' column
was dropped from 'example' table earlier. The statement currently produces
a different error, because anytable cannot be passed to PREPARE, but if
that worked, this would fail because of the broken ORDER BY. The purpose
of this test is to test PREPARE with anytable, so let's not have a broken
ORDER BY.

Just to keep the normal expected output and ORCA expected output as close
to each other as possible. You do get those NOTICEs when you run the
queries, but they are ignored thanks to the "init-file" we use.

Reformat some of the test queries, and make sure the formatting is the same
between the .sql file and .out file (pg_regress uses "diff -w", which masks
out some of the differences, but it was annoying while doing a manual diff).

pg_regress uses gpdiff.pl to mask differences in costs etc. of EXPLAIN
output, so that trivial changes in the plan output don't cause a
regression failure. That mechanism didn't work for this EXPLAIN query,
because the "explain" and "select" were on different lines. Remove the
newline, to make gpdiff.pl recognize the query as an EXPLAIN query, to
make the test case less fragile.

I noticed while debugging an issue with PartitionSelectors on the 8.3
merge branch, that we don't have a test case for this.

Commit 879de2bc added a test case for naming output columns of append
nodes, but forgot to update the non-ORCA expected output.

Seems more straightforward. Firstly, modifying a PlannedStmt at execution
is dubious, if the PlannedStmt is reused for executing the same query
again. Secondly, if the original Query objects are indeed not needed
after planning, we can save a little bit of memory, and avoid the overhead
of stripping the plan on every execution. This also makes any breakage
more obvious, if it turns out that the Query is actually still needed
at execution for some reason, as that issue would then show up on the
first execution already, and not only on reuse of a PlannedStmt.

Per Kenan Yao's observation that stripPlanBeforeDispatch() also scribbles
on the PlannedStmt.

This is also transient information, only valid during execution, and should
not be cached with the plan.

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).

This isn't a problem right now, but with PostgreSQL 8.3, PlannedStmt is
supposed to be immutable, because plan caching works by saving the
PlannedStmt. So let's tidy this up, before we merge that from the upstream.
There are more GPDB-added fields in there that are modified, but this is a
start.

If there are two InitPlan nodes inside each other, and the outer InitPlan
never executes the inner InitPlan (because the value of the outer InitPlan
was determined without it), don't get confused when some of the params
are not set (= won't even have a valid type OID)

bfv_subquery regression tests exercised this. It failed with
--enable-cassert. Fixes github issue #500.

This fixes the test failure introduced in commit effc38f6

fixes #809
[delivers #120723853]

This commit generates code for a naive code-generated version of ExecQual that simply fallbacks to regular ExecQual.
The code-generated ExecQual is enrolled in the existing codegen framework and is called only in ExecScan.
After the implementation of the function (i.e., generate code for expression evaluation), we can replace all calls to regular ExecQual with call_ExecQual macros.

 * Address a number of cpplint errors
 * Fix files and variable naming for ExecVariableList codegen
 * Ignore Testing directory created by ctest

The 8.3 merge added a new opr_sanity test that caught that. But it's
been broken all along, so fix it now. We'll get the regression test later,
with the merge.

Backport this bugfix from PostgreSQL 9.0, because we had backported
src/timezone or at least localtime.c from 9.0. This brings localtime.c
in sync with the tip of REL9_0_STABLE. (PostgreSQL 9.0 is end-of-life
already, so there won't be any more fixes in that branch in the upstream.)

commit 6b87144323fe4cf920ea4d095cce93a84c9b8922
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Wed Apr 25 17:25:30 2012 -0400

    Fix edge-case behavior of pg_next_dst_boundary().

    Due to rather sloppy thinking (on my part, I'm afraid) about the
    appropriate behavior for boundary conditions, pg_next_dst_boundary() gave
    undefined, platform-dependent results when the input time is exactly the
    last recorded DST transition time for the specified time zone, as a result
    of fetching values one past the end of its data arrays.

    Change its specification to be that it always finds the next DST boundary
    *after* the input time, and adjust code to match that.  The sole existing
    caller, DetermineTimeZoneOffset, doesn't actually care about this
    distinction, since it always uses a probe time earlier than the instant
    that it does care about.  So it seemed best to me to change the API to make
    the result=1 and result=0 cases more consistent, specifically to ensure
    that the "before" outputs always describe the state at the given time,
    rather than hacking the code to obey the previous API comment exactly.

    Per bug #6605 from Sergey Burladyan.  Back-patch to all supported versions.

This was useful while debugging on the 8.3 merge branch. It might come
handy in the future too, and it's cheap.

The convenience routine isn't really all that convenient. Aside from
refactoring, this turns the NULL checks from an Assert to elog(). Seems more
robust. (I happened to hit the assertion, while hacking on something else.)

This was done in the upstream earlier already, in commit 8b4ff8b6, but there
were a few GPDB-added error messages left. Fix those too, for consistency.

This is inside an if-check that checks the same. Plus some whitespace fixes.
Caught my eye while debugging..

There's no need to be able to read nodes generated by an old version. We're
not going to handle upgrades that way.

Not strictly necessary, but couldn't resist..

The VERBOSE option was always ignored, so this is no loss in functionality,
you just can't add that noiseword there anymore. According to git history,
this was added to the syntax back in 2009, for "PostgreSQL compatibility",
but AFAICS PostgreSQL has never had VERBOSE option for CLUSTER, so I have
no idea what that was all about. It's possibly worth noting in release
notes as a backwards-incompatibility, though.

Having a "checkpoint.h", corresponding to "checkpoint.c", makes perfect
sense, but those function definitions are in bgwriter.h in PostgreSQL, and
keeping the code as close to upstream as possible trumps the consistency of
keeping definitions for "foo.c" in header file called "foo.h". Keeping
things close to upstream makes merging easier.

These created merge conflicts while working on the 8.3 merge. In order to
keep that upcoming big merge slightly smaller, cherry-pick this change to
master now. pg_depend.c was already completely identical to the PostgreSQL
8.3 version, except for the use of CaQL.

Well, almost: there was also one instance of changing an old
heap_formtuple() call to the new heap_form_tuple() interface. I kept that
change. But other than that, the file is now 100% identical to upstream.

We don't particularly care about performance on Solaris at the moment, and
have no Solaris systems to test on. Let's just rely on the upstream
defaults, and revert this change to reduce our diff footprint vs. upstream.

If a page has hint bits set, but the buffer has not been marked as dirty,
and it gets evicted between the 1st and 2nd vacuum pass, the 2nd pass
gets upset. That can't happen in the upstream, as setting a hint bit
always marks the buffer as dirty, but that is not guaranteed in GPDB, because
of gp_disable_tuple_hints.

Includes tests:
  composite_keys_gpdb_1
  composite_keys_gpdb_3
  composite_keys_gpdb_2
  partitionindexes
  staticselection
  cte_functest
  cte_queries
  create_table_default_distribution
  lastj lastj_hash
  indexapply

Commit 33a1278c merged upstream addition of a typmod argument to
makeConst(). However, one of the calls was botched during the merge, and
the typmod argument was inserted to wrong place in argument list. This
seems to have been harmless because the constant ended up being NULL
anyway, and the bogus values for the other arguments were ignored.

These got in the way in the PostgreSQL 8.3 merge, so let's get them over
with before the big merge lands.