Closes #449

Most of these test additions are inspired from Pivotal's internal
testing and needed to be added to the open source installcheck to
give the community more test coverage.

If a PathKey contains a constant member, it can be evaluated without
any entries in the target list, and can always be returned in
cdbpullup_findPathKeyExprInTargetList. This fixes the "Unexpected intarnal
error" you got with the included test query.

Closes issue #348, reported by liruto. Thanks for the report!

When DELETEing or UPDATEing an inherited table, some tables in the
inheritance tree might need an explicit Motion node to bring the targeted
tuples back to the segment where they reside, and some might not. The code
to build the plan handled that correctly, but this assertion incorrecly
assumed that it's all or nothing.

Remove the assertion, as it doesn't seem very useful in the first place.
The code that inserted the Motion nodes is just above the assertion, and
the assertion was basically just testing the same thing that the code
just did, and not some general invariant that should always hold.

Fixes issue #332

More fallout from the equivalence classes merge.

It's easy to see that the code was broken, as it would always return 'true'
regardless of what happened in the for-loop.

column compression tests perform bunch of alter type commands,
affecting other tests. Better to perform such opertions on dedicated database.

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

master before dispatching the command to segments.

gp_truncate_error_log() function first dispatches the permissions check to the
segments and prints out the results before performing the check on the master.
This makes it hard to test this function if the cluster is configured with a
different number of segments than the test since different number of segments
produce different number of lines in the output. Performing the check first on
the master will cause the transaction to error out immediately and will be
easier to test.

segments configured in the cluster.

This reverts commit 8443c62e.

There is nothing special about these tables, views, or functions. We have
tons of objects like this all over the place. Let's just drop these.

The countrylist1 table was not used for anything either.

Makes it run a bit faster, I hope.

Now that some of the objects are created in 'regression' database, rather
than a newly created database, rename some objects to avoid clashing with
other bugbuster tests that use the same object names.

I wondered for a long time, why there are two copies of some DDL statements
in the .sql file, but only one copy in the .out file, and the test still
passes. Turns out that some of the DDL commands in the test file were inside
COPY data block. Instead of using valid-looking DDL as test data, put a
more explicit notice there. Perhaps putting a long block of valid queries
after a bogus "\.   " marker is a useful thing to test, but the point of the
test really should be explained explicitly.

heap_table_drop_col3 database is never created, so there's no point trying
to drop it. And no point in dropping objects in the db_test_bed database
in the beginning of the test: they won't exist, because we just created the
database.

Surely we have enough test coverage for creating a database with a regular,
lower-case name, or one with a number in it. We do both of those things
as part of initdb, for example.

Makes it nicer to run the test manually with pg_regress.

We don't do DROP LANGUAGE in the test (anymore. The bogus output is
ignored, but let's be tidy.

With PostgreSQL, if you do "SELECT * FROM foo WHERE id = 1 and id = 2",
you get a Scan node on foo, with a gating Result node with False one-time
filter. That's what you also got on GPDB before this patch. Before merging
the equivalence classes patch, however, you got a Result node with
False one-time filter, with no subplan. This patch changes the behaviour
back to that.

Avoiding the planning saves some time during planning, as we don't need
to decide how to scan the relation. But more importantly, a stand-alone
Result node with no subplan can be executed on any segment, so the planner
can avoid unnecessary Motion nodes in some cases.

In the recent work to port tests from tinc to icg a duplicate entry
for this testsuite snuck in.

Earlier tests only worked if was run with cluster having 2 segments, if
number of segemnts changed the output differed and hence will cause
test failure, which shouldn't be the case.

Tests ported from Pivotal's TINC test suite.

Incremental backup uses modcount to decide if AO/CO table needs to be
included for incremental backup. So, update or delete to AO/CO must
increment the modcount, this adds validation for the same to ICG instead
of having it in some other complicated test framework.

Yes, append-only tables are not actually append-only in modern version of
GPDB, hence the oxymoronic name.

These tests are ported from Pivotal's TINC test suite which has not been
open sourced - we are porting tests out of the suite instead.

These tests have been ported from TINC which is a test framework used inside
pivotal.

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.