Use the available macro for detecting FTP protocol and use pstrdup
instead of palloc+strncpy. Also fix a spacing issue with an ereport
call.

Mostly, move the responsibilities of the check_call() function to the
callers, transformAggregateCall() and transformWindowFuncCall().

This fixes one long-standing, albeit harmless, bug. Previously, you got an
"Unexpected internal error", if you tried to use a window function in the
WHERE clause of a DELETE statement, instead of a user-friendly syntax
error. Add a test case for that.

Move a few similar tests from 'olap_window_seq' to 'qp_olap_windowerr'.
Seems like a more appropriate place for them. Also, 'olap_window_seq' has
an alternative expected output file for ORCA, so it's nice to keep tests
that produce the same output with or without ORCA out of there. Also add a
test query for creating an index on an expression containing a window
function. There was a test for that already, but it was missing parens
around the expression, and therefore produced an error already in the
grammar.

This reverts commit f71e57c6, better to
keep the behavior.

The other one is <SEG_DATA_DIR>, they should keep the same style.

In GpMirrorListToBuild.buildMirrors() if there are no mirrors to
build, then return True, so that gprecoverseg returns a return code
of 0.
Signed-off-by: NShoaib Lari <slari@pivotal.io>
Signed-off-by: NNadeem Ghani <nghani@pivotal.io>

Deleting unused function CreateCurlHandler and make some other functions static
to avoid warnings.

With commit cedd89bf "Simplify tuple
serialization in Motion nodes.", the usage for this function was removed.

These functions as inline functions were producing warnings, based on discussion
https://groups.google.com/a/greenplum.org/d/msg/gpdb-dev/6fgKvN9QpV4/zjysjqIZAgAJ
converting them to macro as upstream. Adding explicit type casting wherever
needed now that DatumGetPointer() returns (char *) instead of (void *).

Compiling hstore was generating the warning for using deprecated function
heap_formtuple(). Fixing to use the newer one heap_form_tuple().

Back-patch commit 4e182361
(another thing that longfin's version of clang doesn't like).

This avoids a warning from clang 3.2 about an uninitialized variable
'dtype' in date_in().

This commit removes Query::hasModifyingCTE and
ParseState::p_hasModifyingCTE because they are dead code.

This change impacts reading and writing `pg_rewrite` rules, which is how
views are implemented, and hence won't be backported to 5.0 or ealier. A
`pg_upgrade` from 5 to 6 will still work because this change has no DDL
surface.

* whitespace reformat
Signed-off-by: NShoaib Lari <slari@pivotal.io>

* gprecverseg unit test: remove redundancy
Signed-off-by: NShoaib Lari <slari@pivotal.io>

* Fix gprecoverseg recursive behavior

gprecoverseg called itself during a rebalance, through a Command object.
But this command didn't signal failures through a non-zero ret-code. So
the top-level gprecoverseg didn't check its stdout/stderr for error
messages and didn't echo them to its own stdout, though they were being
logged.

This commit changes behavior so gprecoverseg make another object and
invokes its run() method. Any errors are now shown to the user and
logged.
Signed-off-by: NMarbin Tan <mtan@pivotal.io>
Signed-off-by: NNadeem Ghani <nghani@pivotal.io>

Refactor the EDGE_IS_* macros so that they take the current
WindowStatePerLevel as argument, rather than a WindowFrameEdge. This will
make the transition to the upstream window function implementation a bit
easier, because the upstream implementation doesn't have a WindowFrameEdge
struct.

Encapsulate access to level_state->is_rows in a macro. This is also in
preparation for the upstream implementation, which will contain that
information as a flag in the frameOptions bitmask.

Many functions used an 'is_lead' argument, and one used 'is_trail', to
keep track whether we're dealing with the leading or trailing edge.
Introduce a little enum with EDGE_TRAIL and EDGE_LEAD values, to avoid
having to remember what 'true' or 'false' means in which context.

This reverts commit 118ab14f.

In principle, it makes sense to determine at plan-time, whether the
expression needs to be re-evaluated for every row. In practice, it seems
simpler to decide that in the executor, when initializing the Window node.
This allows removing a bunch of code from the planner, and from the ORCA
translator, including the hack to force the expression to be delayed if it
was a SubLink.

The planner always set the delayed flag, unless the expression was a Const.
We can easily and quickly check for that in the executor too. I'm not sure
how ORCA decided whether to delay or not, but in some quick testing I
cannot come up with a case where it would decide differently.

The big difference is that each leaf query is now transformed in one go,
like it's done in the upstream, instead of transforming the target list
and FROM list first. That partial transformation was causing trouble for
another refactoring that I'm working on, which ill change the way window
functions are handled in parse analysis.

This two-pass code is GPDB-specific, PostgreSQL uses a simpler algorithm
that works bottom-up, one setop node at a time, to select the column types.

It hasn't been implemented, but there is basic support in the grammar,
just enough to detect the syntax and throw an error or ignore it. All the
rest was dead code.

The feature was removed in GPDB 5. Apparently no-one has been running these
tests, because they'd fail.

comment out several tests which will fail on CCP cluster

Verify the newval for GUC 'statement_mem' and 'max_resource_groups' only if they are actually being set.

In the process of starting gpdb, one step is to check if all GUCs are valid with new values, but without actually setting them.

This makes the linux directions look more like the macOS directions for the top level readme.

* Updated PXF notice and licensing info

* Updated PXF notice and licensing info

Currently ORCA does not support index scan on leaf partitions. It only supports
index scan if we query the root table. This commit along with the corresponding
ORCA changes adds a support for using indexes when leaf partitions are queried
directly.

When a root table that has indexes (either homogenous/complete or
heterogenous/partial) is queried; the Relcache Translator sends index
information to ORCA.  This enables ORCA to generate an alternative plan with
Dynamic Index Scan on all partitions (in case of homogenous index) or a plan
with partial scan i.e. Dynamic Table Scan on leaf partitions that  don’t have
indexes + Dynamic Index Scan on leaf partitions with indexes (in case of
heterogeneous index).

This is a two step process in Relcache Translator as described below:

Step 1 - Get list of all index oids

`CTranslatorRelcacheToDXL::PdrgpmdidRelIndexes()` performs this step and it
only retrieves indexes on root and regular tables; for leaf partitions it bails
out.

Now for root, list of index oids is nothing but index oids on its leaf
partitions. For instance:

```
CREATE TABLE foo ( a int, b int, c int, d int) DISTRIBUTED by (a) PARTITION
BY RANGE(b) (PARTITION p1 START (1) END (10) INCLUSIVE, PARTITION p2 START (11)
END (20) INCLUSIVE);

CREATE INDEX complete_c on foo USING btree (c); CREATE INDEX partial_d on
foo_1_prt_p2 using btree(d);
```
The index list will look like = { complete_c_1_prt_p1, partial_d }

For a complete index, the index oid of the first leaf partitions is retrieved.
If there are partial indexes, all the partial index oids are retrieved.

Step 2 - Construct Index Metadata object

`CTranslatorRelcacheToDXL::Pmdindex()` performs this step.

For each index oid retrieved in Step #1 above; construct an Index Metadata
object (CMDIndexGPDB) to be stored in metadata cache such that ORCA can get all
the information about the index.
Along with all other information about the index, `CMDIndexGPDB` also contains
a flag `fPartial` which denotes if the given index is homogenous (if yes, ORCA
will apply it to all partitions selected by partition selector) or heterogenous
(if yes, the index will be applied to only appropriate partitions).
The process is as follows:
```
	Foreach oid in index oid list :
		Get index relation (rel)
		If rel is a leaf partition :
			Get the root rel of the leaf partition
			Get all	the indexes on the root (this will be same list as step #1)
			Determine if the current index oid is homogenous or heterogenous
			Construct CMDIndexGPDB based appropriately (with fPartial, part constraint,
			defaultlevels info)
		Else:
			Construct a normal CMDIndexGPDB object.
```

Now for leaf partitions, there is no notion of homogenous or heterogenous
indexes since a leaf partition is like a regular table. Hence in `Pmdindex()`
we should not got for checking if index is complete or not.

Additionally, If a given index is homogenous or heterogenous needs to be
decided from the perspective of relation we are querying(such as root or a
leaf).

Hence the right place of `fPartial` flag is in the relation metadata object
(CMDRelationGPDB) and not the independent Index metadata object (CMDIndexGPDB).
This commit makes following changes to support index scan on leaf partitions
along with partial scans :

Relcache Translator:

In Step1, retrieve the index information on the leaf partition and create a
list of CMDIndexInfo object which contain the index oid and `fPartial` flag.
Step 1 is the place where we know what relation we are querying which enable us
to determine whether or not the index is homogenous from the context of the
relation.

The relation metadata tag will look like following after this change:

Before:
```
	<dxl:Indexes>
		<dxl:Index Mdid="0.17159874.1.0"/>
		<dxl:Index Mdid="0.17159920.1.0"/>
	</dxl:Indexes>
```

After:
```
	<dxl:IndexInfoList>
		<dxl:IndexInfo Mdid="0.17159874.1.0" IsPartial="true"/>
		<dxl:IndexInfo Mdid="0.17159920.1.0" IsPartial="false"/>
	</dxl:IndexInfoList>

```

A new class `CMDIndexInfo` has been created in ORCA which contains index mdid
and `fPartial` flag.  For external tables, normal tables and leaf partitions;
the `fPartial` flag will always be false.

Hence at the end, relcache translator will provide list of indexes defined on
leaf partitions when they are queried directly with `fPartial` being false
always. And when root table is queried; the `fPartial` will be set
appropriately based on the completeness of the index.  ORCA will refer to
Relation Metadata for fPartial information and not to the indepedent Index
Metadata Object.

[Ref ##120303669]

* In ruleutils.c, the ereport() was broken. Use elog() instead, like in
  the upstream. (elog() is fine for "can't happen" kind of sanity checks)

* Remove a few unused local variables.

* Add a missing cast from Plan * to Node *.

Solves https://github.com/greenplum-db/gpdb/issues/3176

We will be less conservative and enable by default recursive CTE on
master, while keeping recursive CTE hidden as we progress on developing
the feature.

This reverts the following two commits:
* 280c577a "Set gp_recursive_cte_prototype GUC to true in test"
* 4d5f8087 "Guard Recursive CTE behind a GUC"
Signed-off-by: NHaisheng Yuan <hyuan@pivotal.io>
Signed-off-by: NJesse Zhang <sbjesse@gmail.com>

In a stand-alone backend ("postgres --single"), you cannot realistically
expect any of the infrastructure needed for MPP processing to be present.
Let's force a stand-alone backend to run in utility mode, to make sure
that we don't try to dispatch queries, participate in distributed
transactions, or anything like that, in a stand-alone backend.

Fixes github issue #3172, which was one such case where we tried to
dispatch a SET command in single-user mode, and got all confused.

Previously we were setting the value of
`optimizer_join_arity_for_associativity_commutativity` to very large
number and so ORCA would spend a very long time evaluating all possible n_way_join
combinations to come up with the cheapest join tree to use in the plan.

We are reducing this value to `7` as it does not prove to be beneficial
to spend time and resources to evaluate any more than 7_way_joins in
trying to find the cheapest join tree.

The upstream repository for the resource type has been renamed. There
are no changes to the functionality, just a change of name.