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

segments configured in the cluster.

This reverts commit 8443c62e.

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.

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.

Hence, it won't interfere with parallel executed tests.
The database creation overhead is less than 1 sec on a warm instance.

[#111625692]
Signed-off-by: NJacob Frank <jfrank@pivotal.io>

We shouldn't error out if plpythonu already exists, it's required for
the test to run but it's not the thing we're testing here.

We have a list of window values, one per level that the window functions of each level processes. We extract these window values from tuple store. To do the extraction, we use a temporary buffer, called serial_array, to serialize and deserialize the tuples. During this process, we obtain winvalues (the list of input values for a level). If the data type of the winvalues for a level is byref, then it ends up holding a pointer to the serial_array. However, we have only one serial_array for the entire window operator. Therefore, if we have more than one level with byref data types, we may end up overwriting the serial_array when we process another level, corrupting the earlier level’s byref datum pointers. To fix this, we now have one serial_array per level.
Signed-off-by: NFoyzur Rahman <foyzur@gmail.com>

Closes #299.

The test query used system tables pg_class and gp_configuration, which is
fine, except that the cost of scanning pg_class can vary widely, depending
on previous regression tests and the amount of relations created in them.
That made the output of the case a bit unstable; the planner might swap
the inner and outer sides of the nestloop join between pg_class and
gp_configuration, depending on the circumstances. That has been stable
so far, but started to cause grief on another patch I'm working on, which
changes the way ANALYZE works, because apparently it changed the statistics
collected for pg_class sligthly.

To fix, replace pg_class and gp_configuration in the test query with regular
tables, created specifically for the test case. While we're at it, simplify
the query a little bit, and also add a comment explaining what the purpose
of the test is. There doesn't actually seem to be any need to do EXPLAIN
here, the query produces wrong results if the bug is present, so get rid
of that too.

I tested this by reverting the changes that fixed the original bug this test
query was added for, and verifying that the new query also produces wrong
results with that.