Remove old error message at function creation
Fix for bug ID : 3515461: DELETE query with non-pushable clauses does not work.

Two issues were fixed:

1. When the target list is not in the order of the table columns, WHERE clause
was not getting correctly applied. So, at the time of applying the quals, re-arrange
the slot values into an intermediate slot, so as to make the values ordered in line
with the order of the table attributes, and then apply the qual.

2. When WHERE clause contains subquery that refers to attributes in outer query,
the DELETE query fails, because the function pull_var_clause() that is used to
extract the qual vars into the target list does not peek into subquery. So replaced
this walker with a new walker that extracts vars from subquery as well.

More details about the fix are available in the bug comments.
Callback mechanism on GTM for sequence renaming

Addition of a callback at transaction abort to change a sequence on GTM
back to its former name in case it has been changed during this transaction.
A new regression test called xc_sequence is added with test cases for
sequence creation and drop callback, and renaming callback.
Addition of an alternate output file for test select_implicit

Former PostgreSQL has 3 different output files due to diffs in ORDER BY of
test_missing_target. Up to now only one file was used for XC but the same
diffs are reproducible depending on environment used. Hence a necessary
output file is added.
While generating remote column aliases, make use of user-supplied column
aliases if available, and use the physical table attributes only if
user has not supplied column aliases. The issue was: if a remote join
query has user column aliases, they were not getting used in the quals
of remote join query, and so the query used to give error such as:

SELECT '' AS "xxx", t1.a, t2.e
 FROM J1_TBL t1 (a, b, c), J2_TBL t2 (d, e)
  WHERE t1.a = t2.d
   ORDER BY a, e;
ERROR:  column in_1.i does not exist
Fix for regression test privileges

Strengthen consistency of test in cluster by adding a couple of
ORDER BY clauses and correct output in consequence of commit 8b70821
that reallowed non-superusers to create stable and volatile functions.
Block creation of SQL functions containing utility statements

To support these functions we need to first implement a deparser
for all utility statements and then use the deparsed utility statement
while adding remote query node in ProcessUtility function.
Currently we are using "queryString" which can contain multiple
statements in case of SQL functions, some of which can be utility
and the last one has to be a select. Having such a combination in
a single remote query node creates problems while processing results.

Since that deparser is not there yet, we have to block creation of such SQL functions.

By setting the GUC check_function_bodies of OFF, one can by-pass the code
to block the creation of such functions. This patch makes the necessary
changes to make sure that such SQL functions do not produce any crash,
although they still won't run successfully.

The documentation is changed to let the users know of this limitation.

A few test cases are also added.
Fix for test case sanity_check

XC has added three catalog tables hence they are expected in the output.
Composite indexes are not supported so creation of such an index on func_index_heap fails.
pg_regress: rowtypes.sql : An update having references like column.* generates
ERROR:  Cannot generate remote UPDATE plan. Since we are not going to fix the
issue in release 1.0, this commit accommodates this ERROR message in
rowtypes_1.out so as to make the test pass. rowtypes_1.out also had some old
changes which are not required now, so removed those.
Fix the test case create_index. The test case was failing because of the following reasons

1. There was a problem in CTAS. While doing the create table step QueryRewriteCTAS
   was wrongly assuming that the new table to be created has to be created with
   NOT NULL constraint for all columns, where as in PG the table created as a
   result of CTAS has no such constraint added by default,
   even if the table from which we are selecting has any such constraint.

2. We added an id column to the polygon_tbl. This change had an impact on
   a couple of test cases here too.

3. In XC, EXPLAIN show the plan of coordinator only, whereas in this test case
   there seems to be a need to show the plans of data node. Added a feature
   request 3522479 for this and changed the expected output file for now.

4. Removed alternate expected output file.
Addition of new output files for collate, tsearch and xc_distkey

Those tests are using additional ORDER BY clauses on some queries
to make data obtained in the cluster consistent but those three tests
might have ordering output that can change depending on the environment
where XC is running.
Fix for Bug 3498157 : pg_relation_size bug

For exec-direct, the super-user restriction is applied in parse/analyse phase.
So, create  SPI function SPI_execute_direct() specially to allow
running internal SQLs directly on other nodes, transparent to the user. This
function bypasses the parsing stage by creating an ExecDirectStmt node manually
and then does the usual analyze, rewrite, plan and execute using the usual
SPI interface functions. This allows us to bypass the super-user restriction
which is now shifted from analyze phase to parse phase.

So for this release 1.0 we leave the exec-direct super-user restriction, but
allow to propagate SQLs to other nodes through backend code. This prevents
normal users from accidentally doing table writes using exec-direct but at the
same time allows transparently to propagate system functions like
pg_relation_size, pg_advisory_lock() etc to be propagated to coordinators and/or
datanodes transparently.
Merge branch 'master' into plpgsql