This commit adds the GPDB side changes required to support GIN Indexes with
ORCA.  It also adds a new test file gp_gin_indexes to test plans produced for
ORCA/planner.

GIN indexes are not supported with index expression or predicate constraints.
ORCA does not support it currently for other types of indexes too.

Git stores the 'x' flag for files in the repository. For no good reason,
some files had it set differently from upstream. It's harmless, but let's
avoid spurious differences.

Remove the obsolete comment for RETURNING and put the test in a parallel running group, following pg upstream.

This feature will not be supported in the oncoming gpdb major release.
Explicitly disable it for now.

Recently, ICW case 'select_into' failed intermittently, the error looks like

"CREATE TABLE selinto_schema.tmp3 (a,b,c)
 	   AS SELECT oid,relname,relacl FROM pg_class
 	   WHERE relname like '%c%';	-- OK
ERROR:  role "30973" does not exist"

The RCA is, case 'lock' should not run concurrently with 'select_into',
a minirepo is:

1. in 'lock' case
CREATE TABLE lock_tbl1 (a BIGINT);
CREATE ROLE regress_rol_lock1;
GRANT UPDATE ON TABLE lock_tbl1 TO regress_rol_lock1;
select oid, relname, relacl from pg_class where relname like '%c%';
  oid   |  relname  |                        relacl
--------+-----------+-------------------------------------------------------
 180367 | lock_tbl1 | {gpadmin=arwdDxt/gpadmin,regress_rol_lock1=w/gpadmin}

2. in 'select_into' test case
CREATE TABLE selinto_schema.tmp3 (a,b,c)
       AS SELECT oid,relname,relacl FROM pg_class
       WHERE relname like '%c%';

3. in 'lock' test case
DROP TABLE lock_tbl1;
DROP ROLE regress_rol_lock1;

4. in 'select_into' test case
select * from tmp3;
   a    |     b     |                     c
--------+-----------+--------------------------------------------
 180367 | lock_tbl1 | {gpadmin=arwdDxt/gpadmin,180370=w/gpadmin}

create table tmp4 as select * from tmp3;
NOTICE:  Table doesn't have 'DISTRIBUTED BY' clause. Creating a NULL policy entry.
ERROR:  role "180370" does not exist

In Step4, role 'regress_rol_lock1' has been dropped, so when it tries to parse
acl, it finds role "180370" does not exist, the error seems to be reasonable.

In upstream, test 'lock' doesn't run concurrently with 'select_into', I also notice
that we have two 'lock' test within parallel_schedule, so remove the first one
to match upstream and avoid the intermittent failure of 'select_into'

This commit adds the support and option of `mpp_execute 'MASTER | ANY |
ALL SEGMENTS'` for foreign tables.

MASTER is the default, FDW requests for data from master.

ANY, FDW requests for data from master or one any segment, depends on
which path costs less.

ALL SEGMENTS, FDW requests for data from all segments, wrappers need to
have a policy matching the segments to data.

For instance, file_fdw probes the mpp_execute vaule, then load different
files based on the segment number. But something like gpfdist on the
foreign side doesn't need this, which hands out a different slice of the
data to each request, all segments could request the same location.

This commit does three things:
  - move reshufle tests to greenplum_schedule
  - add cases to test that reshuffle can correctly abort
  - remove some redundant cases(I think in this regress
    tests, it is enough to just test expanding from 2 to 3)

Now we have  partial tables and flexible GANG API, so we can allocate
GANG according to numsegments.

With the commit 4eb65a53, GPDB supports table distributed on partial segments,
and with the series of commits (a3ddac06, 576690f2), GPDB supports flexible
gang API. Now it is a good time to combine both the new features. The goal is
that creating gang only on the necessary segments for each slice. This commit
also improves singleQE gang scheduling and does some code clean work. However,
if ORCA is enabled, the behavior is just like before.

The outline of this commit is:

  * Modify the FillSliceGangInfo API so that gang_size is truly flexible.
  * Remove numOutputSegs and outputSegIdx fields in motion node. Add a new
     field isBroadcast to mark if the motion is a broadcast motion.
  * Remove the global variable gp_singleton_segindex and make singleQE
     segment_id randomly(by gp_sess_id).
  * Remove the field numGangMembersToBeActive in Slice because it is now
     exactly slice->gangsize.
  * Modify the message printed if the GUC Test_print_direct_dispatch_info
     is set.
  * Explicitly BEGIN create a full gang now.
  * format and remove destSegIndex
  * The isReshuffle flag in ModifyTable is useless, because it only is used
     when we want to insert tuple to the segment which is out the range of
     the numsegments.

Co-authored-by: Zhenghua Lyu zlv@pivotal.io

Each table has a `numsegments` attribute in the
GP_DISTRIBUTION_POLICY table,  it indicates that the table's
data is distributed on the first N segments, In the common case,
the `numsegments` equal the total segment count of this
cluster.

When we add new segments into the cluster, `numsegments` no
longer equal the actual segment count in the cluster, we
need to reshuffle the table data to all segments in 2 steps:

	* Reshuffle the table data to all segments
	* Update `numsegments`

It is easy to update `numsegments`, so we focus on how to
reshuffle the table data, There are 3 type tables in the
Greenplum database, they are reshuffled in different ways.
For the hash distributed table, we reshuffle data based on
Update statement. Updating the hash keys of the	table
ill generate a Plan like:

	Update
		->Redistributed Motion
			->SplitUpdate
				->SeqScan

We can not use this Plan to reshuffle table data directly.
The problem is that we need to know the segment count
when Motion node computes the destination segment. When
we compute the destination segment of deleting tuple, it
need the old segment count which is equal `numsegments`;
n the other hand, we need to use the new segment count to
compute the destination segment for	inserting tuple.
So we have to add a new operator Reshuffle to compute the
destination segment, it records the O and N (O is the count
of old segments and N is the count of new segments), then
the Plan would be adjusted like:

	Update
		->Explicit Motion
			->Reshuffle
				->SplitUpdate
					->SeqScan

It can compute the destination segments directly with O and
N, at the same time we change the Motion type to Explicit,
it can send a tuple to the destination segment which we
computed in the Reshuffle node.

With changing the hash method to the `jump hash`, not all
the table data need to reshuffle, so we add an new
ReshuffleExpr to filter the tuples which are need to
reshuffle, this expression will compute the destination
segment ahead of schedule, if the destination segment is
current segment, the tuple do not need to reshuffle, with
the ReshuffleExpr the plan would adjust like that:

	Update
		->Explicit Motion
			->Reshuffle
				->SplitUpdate
					->SeqScan
						|-ReshuffleExpr

When we want to reshuffle one table, we use the SQL `ALTER
TABLE xxx SET WITH (RESHUFFLE)`, Actually it will generate
an new UpdateStmt parse tree, the parse tree is similar to
the parse tree which is generated by SQL `UPDATE xxx SET
xxx.aaa = COALESCE(xxx.aaa...) WHERE ReshuffleExpr`. We set
an reshuffle flag in the UpdateStmt, so it can distinguish
the common update and the reshuffling.

In conclusion, we reshuffle hash distributed table by
Reshuffle node and ReshuffleExpr, the ReshuffleExpr filter
the tuple need to reshuffle and the Reshuffle node do the
real reshuffling work, we can use that framework to
implement reshuffle random distributed table and replicated
table.

For random distributed table, it has no hash keys,  each
old segment need reshuffle (O - N) / N data to the new
segments, In the ReshuffleExpr, we can generate a random
value between [0, N), if the random values is greater than
O, it means that the tuple need to reshuffle, so SeqScan
node can return this tuple to ReshuffleNode.  Reshuffle node
will generate a random value between [O, N), it means which
new segment the tuple need to insert.

For replicated table, the table data is same in the all old
segments, so there do not need to delete any tuples, it only
need copy the tuple which is in the old segments to the new
segments, so the ReshuffleExpr do not filte any tuples, In
the Reshuffle node, we neglect the tuple which is generated
for deleting, only return the inserting tuple to motion. Let
me illustrate this with an example:

If there are 3 old segments in the cluster and we add 4 new
segments, the segment ID of old segments is (0,1,2) and the
segment ID of new segments is (3,4,5,6), when reshuffle the
replicated table, the seg#0 is responsible to copy data to
seg#3 and seg#6, the seg#1 is responsible to copy data to
seg#4, the seg#2 is responsible to copy data to seg#5.


Co-authored-by: Ning Yu nyu@pivotal.io
Co-authored-by: Zhenghua Lyu zlv@pivotal.io
Co-authored-by: Shujie Zhang shzhang@pivotal.io

We punted on event triggers during the 9.3 merge. This patches up the
OID dispatch of various commands, to make event triggers work, and
re-enables the upstream test.

In GPDB, event triggers only fire in the QD node, not the segments. That
seems like the most sensible behavior. The pg_event_triggers catalog table
is not updated in segments, either, it will stay empty.

There's one remaining issue, marked with FIXME comments: The
pg_event_trigger_dropped_objects() function needs to run in the QD process,
or it errors out, but there's no way to force the planner to do that. So
if you try to use it as part of a more complicated query, it won't work.
One of the upstream tests had to be modified to work around that.

In GPDB AGGREGATE functions can be either 'ordered' or 'hypothetical',
and as a result the token aggr_args has more information than in
upstream. Excepting CREATE [ORDERED] AGGREGATE, the parser will extract
the function arguments from the aggr_args token using
extractAggrArgTypes().

The ALTER EXTENSION ADD/DROP AGGREGATE and SECURITY LIMIT syntax has
been added as part of the merge of PostgreSQL between 9.0 and 9.2, so
add a call to extract the function arguments.
Co-authored-by: NJoao Pereira <jdealmeidapereira@pivotal.io>

Quite a few cases in 'triggers' don't apply on GPDB: non-SELECT statement
in trigger function, modification on views, INSTEAD OF triggers, etc. But
we can still use some of the test cases, for example, FOR STATEMENT trigger
start acting differently since we changed INSERT/DELETE/UPDATE to modifyTable
by merging 8.5, and it should have been caught by the tests.

This reverts commit 4750e1b6.

This is the final batch of commits from PostgreSQL 9.2 development,
up to the point where the REL9_2_STABLE branch was created, and 9.3
development started on the PostgreSQL master branch.

Notable upstream changes:

* Index-only scan was included in the batch of upstream commits. It
  allows queries to retrieve data only from indexes, avoiding heap access.

* Group commit was added to work effectively under heavy load. Previously,
  batching of commits became ineffective as the write workload increased,
  because of internal lock contention.

* A new fast-path lock mechanism was added to reduce the overhead of
  taking and releasing certain types of locks which are taken and released
  very frequently but rarely conflict.

* The new "parameterized path" mechanism was added. It allows inner index
  scans to use values from relations that are more than one join level up
  from the scan. This can greatly improve performance in situations where
  semantic restrictions (such as outer joins) limit the allowed join orderings.

* SP-GiST (Space-Partitioned GiST) index access method was added to support
  unbalanced partitioned search structures. For suitable problems, SP-GiST can
  be faster than GiST in both index build time and search time.

* Checkpoints now are performed by a dedicated background process. Formerly
  the background writer did both dirty-page writing and checkpointing. Separating
  this into two processes allows each goal to be accomplished more predictably.

* Custom plan was supported for specific parameter values even when using
  prepared statements.

* API for FDW was improved to provide multiple access "paths" for their tables,
  allowing more flexibility in join planning.

* Security_barrier option was added for views to prevents optimizations that
  might allow view-protected data to be exposed to users.

* Range data type was added to store a lower and upper bound belonging to its
  base data type.

* CTAS (CREATE TABLE AS/SELECT INTO) is now treated as utility statement. The
  SELECT query is planned during the execution of the utility. To conform to
  this change, GPDB executes the utility statement only on QD and dispatches
  the plan of the SELECT query to QEs.
Co-authored-by: NAdam Lee <ali@pivotal.io>
Co-authored-by: NAlexandra Wang <lewang@pivotal.io>
Co-authored-by: NAshwin Agrawal <aagrawal@pivotal.io>
Co-authored-by: NAsim R P <apraveen@pivotal.io>
Co-authored-by: NDaniel Gustafsson <dgustafsson@pivotal.io>
Co-authored-by: NGang Xiong <gxiong@pivotal.io>
Co-authored-by: NHaozhou Wang <hawang@pivotal.io>
Co-authored-by: NHeikki Linnakangas <hlinnakangas@pivotal.io>
Co-authored-by: NJesse Zhang <sbjesse@gmail.com>
Co-authored-by: NJinbao Chen <jinchen@pivotal.io>
Co-authored-by: NJoao Pereira <jdealmeidapereira@pivotal.io>
Co-authored-by: NMelanie Plageman <mplageman@pivotal.io>
Co-authored-by: NPaul Guo <paulguo@gmail.com>
Co-authored-by: NRichard Guo <guofenglinux@gmail.com>
Co-authored-by: NShujie Zhang <shzhang@pivotal.io>
Co-authored-by: NTaylor Vesely <tvesely@pivotal.io>
Co-authored-by: NZhenghua Lyu <zlv@pivotal.io>

Large objects are currently not supported in Greenplum. Rather than deceive the
user with a non-functional large object api, we disable them for now.

We disable the large object tests in privileges regress test by using ignore
blocks instead of commenting them out or deleting them to reduce merge
conflicts in future postgres merges.
Co-authored-by: NJimmy Yih <jyih@pivotal.io>

Now that we have merged the upstream changes that introduced the
ModifyTable node, it seems like a good time to fix RETURNING. So, here
we go.

Filespaces are no more, remove comment and match schema with
upstream.

This is a backport upstream commit 22817041, from PostgreSQL 9.0, which
added the server version number in the path. But in GPDB, also include the
gp_dbid in the path. This makes it possible to use the same tablespace path
on multiple servers running on the same host, without clashing.

Also includes cherry-pick of the small upstream cleanup commits 5c82ccb1
a6f56efc, and c282b36d.

Re-enable upstream 'tablespace' regression test. It works now, even when
all the nodes are running on same host.

The original name was deceptive because this check is also done for QE
slices that run on master. For example:

EXPLAIN SELECT * FROM func1_nosql_vol(5), foo;

                                         QUERY PLAN
--------------------------------------------------------------------------------------------
 Gather Motion 3:1  (slice2; segments: 3)  (cost=0.30..1.37 rows=4 width=12)
   ->  Nested Loop  (cost=0.30..1.37 rows=2 width=12)
         ->  Seq Scan on foo  (cost=0.00..1.01 rows=1 width=8)
         ->  Materialize  (cost=0.30..0.33 rows=1 width=4)
               ->  Broadcast Motion 1:3  (slice1)  (cost=0.00..0.30 rows=3 width=4)
                     ->  Function Scan on func1_nosql_vol  (cost=0.00..0.26 rows=1 width=4)
 Settings:  optimizer=off
 Optimizer status: legacy query optimizer
(8 rows)

Note that in the plan, the function func1_nosql_vol() will be executed on a
master slice with Gp_role as GP_ROLE_EXECUTE.

Also, update output files
Signed-off-by: NJesse Zhang <sbjesse@gmail.com>

This adds some limitations, and removes some functionality that tte old
implementation had. These limitations will be lifted, and missing
functionality will be added back, in subsequent commits:

* You can no longer have variables in start/end offsets

* RANGE is not implemented (except for UNBOUNDED)

* If you have multiple window functions that require a different sort
  ordering, the planner is not smart about placing them in a way that
  minimizes the number of sorts.

This also lifts some limitations that the GPDB implementation had:

* LEAD/LAG offset can now be negative. In the qp_olap_windowerr, a lot of
  queries that used to throw an "ROWS parameter cannot be negative" error
  are now passing. That error was an artifact of the eay LEAD/LAG were
  implemented. Those queries contain window function calls like "LEAD(col1,
  col2 - col3)", and sometimes with suitable values in col2 and col3, the
  second argument went negative. That caused the error. implementation of
  LEAD/LAG is OK with a negative argument.

* Aggregate functions with no prelimfn or invprelimfn are now supported as
  window functions

* Window functions, e.g. rank(), no longer require an ORDER BY. (The output
  will vary from one invocation to another, though, because the order is
  then not well defined. This is more annoying on GPDB than on PostgreSQL,
  because in GDPB the row order tends to vary because the rows are spread
  out across the cluster and will arrive in the master in unpredictable
  order)

* NTILE doesn't require the argument expression to be in PARTITION BY

* A window function's arguments may contain references to an outer query.

This changes the OIDs of the built-in window functions to match upstream.
Unfortunately, the OIDs had been hard-coded in ORCA, so to work around that
until those hard-coded values are fixed in ORCA, the ORCA translator code
contains a hack to map the old OID to the new ones.

Planner generates plan that doesn't insert any motion between WorkTableScan and
its corresponding RecursiveUnion, because currently in GPDB motions are not
rescannable. For example, a MPP plan for recursive CTE query may look like:
```
Gather Motion 3:1
   ->  Recursive Union
         ->  Seq Scan on department
               Filter: name = 'A'::text
         ->  Nested Loop
               Join Filter: d.parent_department = sd.id
               ->  WorkTable Scan on subdepartment sd
               ->  Materialize
                     ->  Broadcast Motion 3:3
                           ->  Seq Scan on department d
```

For the current solution, the WorkTableScan is always put on the outer side of
the top most Join (the recursive part of RecusiveUnion), so that we can safely
rescan the inner child of join without worrying about the materialization of a
potential underlying motion. This is a heuristic based plan, not a cost based
plan.

Ideally, the WorkTableScan can be placed on either side of the join with any
depth, and the plan should be chosen based on the cost of the recursive plan
and the number of recursions. But we will leave it for later work.

Note: The hash join is temporarily disabled for plan generation of recursive
part, because if the hash table spills, the batch file is going to be removed
as it executes. We have a following story to enable spilled hash table to be
rescannable.

See discussion at gpdb-dev mailing list:
https://groups.google.com/a/greenplum.org/forum/#!topic/gpdb-dev/s_SoXKlwd6I

It seems pretty confusing to have tests named both largeobject and
large_object.  The latter is of very recent vintage (commit ff992c07),
so get rid of it in favor of merging into the former.

Also, enable the LO comment test that was added by commit 70ad7ed4,
since the later commit added the then-missing pg_upgrade functionality.
The large_object.sql test case is almost completely redundant with that,
but not quite: it seems like creating a user-defined LO with an OID in
the system range might be an interesting case for pg_upgrade, so let's
keep it.

Like the earlier patch, back-patch to all supported branches.

Discussion: https://postgr.es/m/18665.1500306372@sss.pgh.pa.us

When performing a pg_upgrade, we copy the files behind pg_largeobject
and pg_largeobject_metadata, allowing us to avoid having to dump out and
reload the actual data for large objects and their ACLs.

Unfortunately, that isn't all of the information which can be associated
with large objects.  Currently, we also support COMMENTs and SECURITY
LABELs with large objects and these were being silently dropped during a
pg_upgrade as pg_dump would skip everything having to do with a large
object and pg_upgrade only copied the tables mentioned to the new
cluster.

As the file copies happen after the catalog dump and reload, we can't
simply include the COMMENTs and SECURITY LABELs in pg_dump's binary-mode
output but we also have to include the actual large object definition as
well.  With the definition, comments, and security labels in the pg_dump
output and the file copies performed by pg_upgrade, all of the data and
metadata associated with large objects is able to be successfully pulled
forward across a pg_upgrade.

In 9.6 and master, we can simply adjust the dump bitmask to indicate
which components we don't want.  In 9.5 and earlier, we have to put
explciit checks in in dumpBlob() and dumpBlobs() to not include the ACL
or the data when in binary-upgrade mode.

Adjustments made to the privileges regression test to allow another test
(large_object.sql) to be added which explicitly leaves a large object
with a comment in place to provide coverage of that case with
pg_upgrade.

Back-patch to all supported branches.

Discussion: https://postgr.es/m/20170221162655.GE9812@tamriel.snowman.net

It was not enabled, because there were a lot of errors in it, because of
features that have been disabled in Greenplum. Like enforcing foreign keys,
INSERT RETURNING, and doing SPI in functions in segments. Those limitations
make these tests a less interesting than in the upstream, but there are
still many good tests in there too. Like the test for anonymous DO blocks,
that are not tested by any other tests.

The .sql file was almost identical to the upstream version. Clean it up
to be even closer, by re-enabling some commented queries in it, removing
the duplicated tests for RETURN QUERY, removing the READS/CONTAINS/MODIFIES
SQL DATA noise words etc.

Memorize the expected output as it is. That's quite different from the
upstream, because of all the disabled functionality, but also because of
some cosmetic differences in error messages.

The 'schema_topology' test contained a copy of the for_vect(), so remove
that, now that we run the real thing.

During the merge of upstream releases there are FIXME comments added
to the codebase for various reasons. Ensure that the FIXME marker is
using a single format to make it easier to grep; GPDB_XX_MERGE_FIXME
was the most frequently used so settle for that.

To test, backport test case for CREATE CAST from PostgreSQL 8.4. We don't
apparently have any coverage for it previously. The upstream commit for the
test case was:

commit a1d2e165
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Date:   Fri Oct 31 09:17:17 2008 +0000

    Add test case for CREATE CAST.

Reported by Yandong Yao

Enhancing PGFuncGeneratorInterface, PGIRBuilderFuncGenerator, and PGGenericFuncGenerator with
attributes and checks that record and examine if a built-in function is strict or not and
generate code accordingly.

Authors: Nikos Armenatzoglou, Nikhil Kak, Jimmy Yih, and Karen Huddleston.

The variadic and default parameters tests are specific to GPDB so
move them to our own regress schedule file.

Like the XML data type, we simply store JSON data as text, after checking
that it is valid.  More complex operations such as canonicalization and
comparison may come later, but this is enough for not.

There are a few open issues here, such as whether we should attempt to
detect UTF-8 surrogate pairs represented as \uXXXX\uYYYY, but this gets
the basic framework in place.

Author:             Álvaro Hernández Tortosa <aht@8kdata.com>
Date:               Mon Mar 14 17:35:20 UTC 2016

doc/src/sgml/datatype.sgml: changed ignored

src/backend/utils/adt/json.c: FIXME: s/errdetail_internal/errdetail/
as errdetail_internal is not supported (yet?) in GPDP.

src/backend/commands/explain.c: code from commit
5384a73f was not merged here as
ExplainStmt->options is not supported yet in GPDB. Code to be merged:
https://github.com/postgres/postgres/commit/5384a73f98d9829725186a7b65bf4f8adb3cfaf1#diff-9ce3cf19c55c48d8714787cf9e3b533f

src/include/catalog/pg_type.h: original PostgreSQL's json and
_json OIDs where 114 and 199. Since 114 is reserved in GPDB, current
assigned OIDs are 3114 and 3199.

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

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

Heikki suggested that we backport atomic operation from PostgreSQL 9.5 to
fix this

    commit b64d92f1
    Author: Andres Freund <andres@anarazel.de>
    Date:   Thu Sep 25 23:49:05 2014 +0200

    Add a basic atomic ops API abstracting away platform/architecture details.

    Several upcoming performance/scalability improvements require atomic
    operations. This new API avoids the need to splatter compiler and
    architecture dependent code over all the locations employing atomic
    ops.

    For several of the potential usages it'd be problematic to maintain
    both, a atomics using implementation and one using spinlocks or
    similar. In all likelihood one of the implementations would not get
    tested regularly under concurrency. To avoid that scenario the new API
    provides a automatic fallback of atomic operations to spinlocks. All
    properties of atomic operations are maintained. This fallback -
    obviously - isn't as fast as just using atomic ops, but it's not bad
    either. For one of the future users the atomics ontop spinlocks
    implementation was actually slightly faster than the old purely
    spinlock using implementation. That's important because it reduces the
    fear of regressing older platforms when improving the scalability for
    new ones.

    The API, loosely modeled after the C11 atomics support, currently
    provides 'atomic flags' and 32 bit unsigned integers. If the platform
    efficiently supports atomic 64 bit unsigned integers those are also
    provided.

    To implement atomics support for a platform/architecture/compiler for
    a type of atomics 32bit compare and exchange needs to be
    implemented. If available and more efficient native support for flags,
    32 bit atomic addition, and corresponding 64 bit operations may also
    be provided. Additional useful atomic operations are implemented
    generically ontop of these.

    The implementation for various versions of gcc, msvc and sun studio have
    been tested. Additional existing stub implementations for
    * Intel icc
    * HUPX acc
    * IBM xlc
    are included but have never been tested. These will likely require
    fixes based on buildfarm and user feedback.

    As atomic operations also require barriers for some operations the
    existing barrier support has been moved into the atomics code.

    Author: Andres Freund with contributions from Oskari Saarenmaa
    Reviewed-By: Amit Kapila, Robert Haas, Heikki Linnakangas and Álvaro Herrera
    Discussion: CA+TgmoYBW+ux5-8Ja=Mcyuy8=VXAnVRHp3Kess6Pn3DMXAPAEA@mail.gmail.com,
        20131015123303.GH5300@awork2.anarazel.de,
        20131028205522.GI20248@awork2.anarazel.de

Remove unnecessary ORDER BY clauses that are not present in the upstream
version. Disable COPY BINARY test, as GPDB doesn't support BINARY copy.
Finally, adjust the error messages in the expected output to match what
you get nowadays.

DROP TABLE cleanup commands have been added to some other tests, so that
the extra user tables don't appear in the output of the 'misc' test. It's
not very nice of the 'misc' test to list all user tables, but this
nevertheless seems less likely to cause merge conflicts than ripping out
that part of the test altogether. There are still differences in the list
of user tables though.

Revert some unnecessary changes compared to upstream: there's no need for
ORDER BYs in queries, gpdiff.pl will mask out row order differences. That
needed some fixes to atmsort.pl though, to make it smarter about reordering
COPY TO STDOUT results. It used to only deal with the COPY (SELECT ...) TO
STDOUT variant, and particularly named tables (COPY .*test1 TO STDOUT). Make
it handle all COPY TO STDOUT commands. Also make it smarter about detecting
the end of COPY TO STDOUT output. In addition to -- or ERROR, also treat any
SELECT, UPDATE, CREATE etc. command as the end of result. In the passing,
remove the "-- copy_stdout" command from atmsort.pl, as it was unused.

No need to label the functions as immutable or with NO SQL or MODIFIES SQL
DATA, and update the error message in the expected output about
cross-segment access within functions.

One of the tests gives a different error than on upstream: an empty line
gives "invalid integer" error in upstream, but "missing data" on GPDB. I'm
not quite sure what's causing that, but both errors seem reasonable for that
case (the "missing data" is perhaps even better), so let's just memorize
that difference.

This lets us remove the large alternative results files for the main
json and jsonb tests, which makes modifying those tests simpler for
committers and patch submitters.

Backpatch to 9.4 for jsonb and 9.3 for json.

As of commit a87c7291 (which later got backpatched as far as 9.1),
we're explicitly supporting the notion that append relations can be
nested; this can occur when UNION ALL constructs are nested, or when
a UNION ALL contains a table with inheritance children.

Bug #11457 from Nelson Page, as well as an earlier report from Elvis
Pranskevichus, showed that there were still nasty bugs associated with such
cases: in particular the EquivalenceClass mechanism could try to generate
"join" clauses connecting an appendrel child to some grandparent appendrel,
which would result in assertion failures or bogus plans.

Upon investigation I concluded that all current callers of
find_childrel_appendrelinfo() need to be fixed to explicitly consider
multiple levels of parent appendrels.  The most complex fix was in
processing of "broken" EquivalenceClasses, which are ECs for which we have
been unable to generate all the derived equality clauses we would like to
because of missing cross-type equality operators in the underlying btree
operator family.  That code path is more or less entirely untested by
the regression tests to date, because no standard opfamilies have such
holes in them.  So I wrote a new regression test script to try to exercise
it a bit, which turned out to be quite a worthwhile activity as it exposed
existing bugs in all supported branches.

The present patch is essentially the same as far back as 9.2, which is
where parameterized paths were introduced.  In 9.0 and 9.1, we only need
to back-patch a small fragment of commit 5b7b5518, which fixes failure to
propagate out the original WHERE clauses when a broken EC contains constant
members.  (The regression test case results show that these older branches
are noticeably stupider than 9.2+ in terms of the quality of the plans
generated; but we don't really care about plan quality in such cases,
only that the plan not be outright wrong.  A more invasive fix in the
older branches would not be a good idea anyway from a plan-stability
standpoint.)

These functions won't throw an error if the object doesn't exist,
or if (for functions and operators) there's more than one matching
object.

Yugo Nagata and Nozomi Anzai, reviewed by Amit Khandekar, Marti
Raudsepp, Amit Kapila, and me.