Port `dml/triggers`
    Port `olap/groupingfunction`
    Port `functions/builtin`
    Port `dml/functional`
    Port `dml/functional/sql_partiton`
    Port `functions/functionProperty`

    Update optfunctional_schedule with ported tests

    Update the Makefile for optimizer functional tests

When SharedScan requests a tuple from the underlying Sort, and the Sort has spilled to disk, the mk_sort code (also the regular sort) makes a copy of the memtuple, but places it in the sortcontext.
When hitting a QueryFinishPending (e.g., master received enough tuples, so stop the execution), EagerFree is called for the entire tree. When reaching the sort node, the sortcontext is deleted, even though the SharedScan above it still has a pointer to a memtuple allocated in this context.

The solution is: pass a memory context for the mk_sort and regular sort to use (change the API and implementation of the following two functions: tuplesort_gettupleslot_pos_mk and tuplesort_gettupleslot_pos). Those functions should use the context provided by the caller to make a copy of the memtuple.
Signed-off-by: NGeorge Caragea <gcaragea@pivotal.io>

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;

In commit d2725929, GPDB marked all allocatedReaderGangs with noReuse flag. When plan contains
init plan and a SET command executed within it, GPDB will mark pre-assigned gangs to noReuse and
destroy them which make query crash

This GUC will be used to control the MEMO size as well as optimization
time for large IN list or large array comparison expressions.

Only the Array with less number of elements than the GUC will be
expanded and participate in constraint derivation.

Trade-off of using this GUC is loss of potential benefits from the
constraint derivation (e.g. conflict detection, partition elimination)
with shorter optimization time and less memory utilization.

The regression database has grown over time, so that it's just above the
1 GB size that the regression test used as a "sanity check". I think the
new zlib regression test broke the camel's back. Bump it up to 5 GB, giving
us about 4 GB of headroom to grow.

If found inconsistent, the free tid list will be rebuilt automatically during
recovery.  During normal operation, super user may invoke the function
gp_persistent_freelist_rebuild(OID) to rebuild the free list.

A basic test case is added to verify sanity of a free tid list rebuilt using
the function.

This closes #815

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.

Merging is easier, when the upstream regression test files (create_index)
are as unmodified as possible, and any GPDB added tests are added to
separate files (bitmap_index). Also, the only planner vs. ORCA differences
in output were in the GPDB-added parts of this, so this allows removing
the ORCA alternative expected output file for the create_index test.

I neglected these in previous commit.

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 function was rewritten in GPDB, and its behaviour was changed to also
return 'true' if the expression contains an Aggref of the given level.
That change in behaviour was made back in 2006, as part of a commit
containing a lot of subquery optimization changes. I could not find an
explanation for that particular change, and all the regression tests pass
without so I assume that it has become obsolete at some point over they
years.

This smoothens the way for future merges with upstream, by reducing the
diff in both code and behaviour. Also, you get a more accurate error
message in a few cases, as seen by the changes to expected output.

As outlined in https://github.com/greenplum-db/gpdb/issues/685 we
have a problem with resetting GUCs in the backends when the GUC
was previously set in the per connection parameter. Explicitly set
this GUC to false since that's the intention with the RESET commands
in these cases to increase robustness of the tests.

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

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.

This fixes the test failure introduced in commit effc38f6

fixes #809
[delivers #120723853]

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.

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

This way we can reuse the csv files in other installcheck suites.

This is a follow-up to commit b7365f58 which replaced the PostgreSQL
bug report email with the Greenplum one.

Removes unused CVS $Header$ tags and moves comments closer to where
they make sense as well as updates a few comments to match reality.

Rather than storing the full 100kb string in the outfile (which adds
200kb for the header) and passing to diff instead compare the tuple
with the expected value and store the boolean result in the outfile
instead.

This shaves 1.25 seconds off the testsuite on my laptop but the
primary win is to shrink the size of the outfiles. Tests on Pulse
show consistently lower diff times.

Invoking gpdiff -version was broken since it relied on an old CVS
$Revision$ tag in the sourcecode to be replaced with an actual value.
Since this clearly isn't the most important part I for now copied
in the contents of VERSION which seems like enough attention to
spend on this.

These variables are not used since the split into a program and a
module.

Rather than our own bespoke code, use the Getopt::Long core module
for parsing the command line options. By specifying pass_through in
the Getopt configuration we can preserve the options to pass down to
the diff command while extracting the gpdiff specific options. The
variants that were previously allowed are added as aliases to the
primary option names.

The tempfile() interface in File::Temp is race free and has been
available as a core module since Perl 5.6.1 (released in April
2001) so replace to simplify the code and avoid excessive looping
around a solved problem.

The PartitionNode tree returned from RelationBuildPartitionDescByOid
will be NULL in case the OID passed isn't present in pg_partition so
we must abort with error to avoid segfaulting on NULL pointer deref.
Also add a test in the partition suite for this.

Reported by Github user @liruto.

Also adding comments in lc_numeric guc for not to
remove GUC_GPDB_ADDOPT

We resolve the path for gpstringsubs.pl with find_other_exec() so
use the outcome of that rather than hardcoding it at invocation.