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.

These tests use the existing fault injection mechanism built into the
server, to cause errors to happen at strategic places, and checks the
results.

This is almost just a placeholder, there are very few actual tests for
now. But it's a start.

The suite uses plain old pg_regress to run the tests and check the
results. That's enough for the tests included here, but in the future
we'll probably want to do server restarts, crashes, etc. as part of
the suite, and will have to refactor this to something that can do those
things more easily. But let's cross that bridge when we get there.

Also, the test actually leaves the connections to the segments in a
funny state, which shouldn't really happen. The test fails currently
because of that; let's fix it together with the state issue. But
even in this state, this has been useful to me right now, to reproduce
an issue on the merge_8_3_22 branch that I'm working on at the same
time (this test currently causes a PANIC there).

This also isn't hooked up to any top-level targets yet; you have to
run the suite manually from the src/test/dtm directory.

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.

These were initialized by constructors earlier. To pass any parameters
for initializing GPOPT or any of its dependendencies, we need to do that
explicitly.

There were a lot of unused tables and functions, and chaff like comments
that are not needed for the actual tests in the file. At first glance,
some of the things seemed marginally useful to test on their own right,
like loading data with non-ASCII characters in it, but all the setup
stuff was in a large ignore-block, so any failures there would go unnoticed
anyway.

Removing unnecessary stuff is a virtue of its own, but this also speeds up
the test nicely.

The stuff that's inherited from upstream stays in create_table, while the
stuff that we've added in GPDB is split off to gp_create_table. Separating
them makes merging and diffing with upstream easier.

The test with stress_test() function (and accompanying tables) was created
and executed once. Then it was dropped, and recreated, and then executed
two times. Executing the same function twice might reveal bugs in plan
caching, so I kept that (although TBH we have better coverage for that
elsewhere). But I don't see the point of dropping and recreating it in
between: surely it's good enough to just create the function once, and
execute it twice.

This reduces the runtime of qp_functions test by about 1/3 (from 3 minutes
to 2 minutes on my laptop).

This commit  generates code for code path: ExecVariableList > slot_getattr > _slot_getsomeattrs > slot_deform_tuple. This code path is executed during scan in simple select queries that do not have a where clause (e.g., select bar from foo;).

For each attribute A in the target list, regular implementation of ExecvariableList retrieves the slot that A comes from and calls slot_getattr. slot_get_attr() will eventually call slot_deform_tuple (through _slot_getsomeattrs), which fetches all yet unread attributes of the slot until the given attribute.

This commit generates the code for the case that all the attributes in target list use the same slot (created during a scan i.e, ecxt_scantuple). Moreover, instead of looping over the target list one at a time, it uses slot_getattr only once, with the largest attribute index from the target list.

If during code generation time, the completion is not possible (e.g., attributes use different slots), then function returns false and codegen manager will be responsible to manage the clean up.

This implementation does not support:
* Null attributes
* Variable length attributes
* Fixed length attributes passed by reference (e.g., uuid)
If at execution time, we see any of the above types of attributes, we fall back to the regular function.

Moreover, this commit:
* renames existing "codegen" guc, which is used for initiating llvm libraries, to "init_codegen" (Note: we set this guc in gpconfig),
* adds guc "codegen", which enables code generation and compilation at query execution time,
* enhances the existing code generation utilities by adding a function that creates all IR instructions for falling back to regular functions, and
* removes the existing code that generates the code of a naive slot_deform_tuple, which simply falls back to regular slot_deform_tuple.
Signed-off-by: NNikos Armenatzoglou <nikos.armenatzoglou@gmail.com>

This reverts commit d3edab91.
The changes to the test are correct. However, there is an issue with gp_primarymirror that causes the ICG tests to fail.
I revert this commit, until we solve the issue with gp_primarymirror.

Commit e0409357 changed size estimation for empty tables, which changed
the plan you get for this query. The new plan looks as good as the old
one, so memorize that as expected output.

Commit 5702a724 changed changed the NOTICE you get when you create a table
with zero columns, but neglected updating expected outputs accordingly.
It went unnoticed because the NOTICEs are masked by the init_file used
in "make installcheck-good". But lets be tidy.

To gpdiff.pl, "---" looks like the beginning of a result set, so it sorts
the rows following that. As long as the test case passes, that doesn't
matter, but if there's a failure, the output diff is mixed up.

While hacking in this area, at one point I broke the code so that a
partition was not correctly in a segment as it should've been, even though
it was locked in the master. Fortunately, I noticed that in manual testing
before committing, but to prevent such bugs from slipping in in the future,
enhance the 'partition_locking' test to catch that kind of bugs.

The int -> text cast (and many other casts to text) were downgraded
to assignment casts in the upstream, and we're about to merge that patch
soon. To prepare for that and to reduce the size of that huge merge
commit somewhat, adjust GPDB test cases to not rely on those casts that
are about to be removed.

When the casts were downgraded in the upstream, it revealed a lot of buggy
queries in applications (or put another way, it broke a lot of applications
:-) ). Many of the queries in our regression tests look bogus like that
as well, for example the "sale.dt < 10" comparison in the qp_olap_mdqa test
(sale.dt is a date). But I didn't try to change the meaning of the queries,
I just added the casts needed to make them do the same thing they used to.
I'm afraid that changing the substance of the queries would reduce our
code coverage, if the tests are reproducing some very specific scenario.