If there are aggregation queries with aliases same as the table actual
columns and they are propagated further from subqueries and grouping is
applied on the column alias it may result in inconsistent targetlists
for aggregation plan causing crash.

	CREATE TABLE t1 (a int) DISTRIBUTED RANDOMLY;
	SELECT substr(a, 2) as a
	FROM
		(SELECT ('-'||a)::varchar as a
			FROM (SELECT a FROM t1) t2
		) t3
	GROUP BY a;

This bumps the copyright years to the appropriate years after not
having been updated for some time.  Also reformats existing code
headers to match the upstream style to ensure consistency.

add_second_stage_agg() builds a SubQueryScan, and moves the "current" plan
underneath it. The SS_finalize_plan() call was misplaced, it needs to be
called before constructing the new upper-level range table, because any
references to the range table in the subplan refer to the original range
table, not the new dummy one that only contains an entry for the
SubQueryScan. It looks like the only thing in SS_finalize_plan() processing
that accesses the range table is processing a TableFunctionScan. That lead
to an assertion failure or crash, if a table function was used in a query
with an aggregate.

Fixes github issue #2033.

The upstream doesn't have it, and it's an odd one out, when none of the
other syscaches have such macros. This reduces our diff vs. upstream, which
makes diffing and merging easier.

I found these with "callcatcher", written by Caolán McNamara. Many thanks
for the tool! See https://www.skynet.ie/~caolan/Packages/callcatcher.html

Finding the tle is a case for breaking the loop early but not finding
isn't a failure case. This elog() breaks the following query in the
gp_dqa testcase when found is properly initiated to false before the
loop.

select count(distinct c), count(distinct dt), i from dqa_t1 group by i;

When not initiated at all the variable was likely to not be false
from randomness and the test didnt fail.

It was quite clearly broken, as it didn't do anything with the new_tle
that it chased up, and the end result was just the same as calling
canonicalize_pathkeys() on the input.

I'm not 100% the code is doing the right thing even with this: If the
pathkey's operator family doesn't match the join clause's operator family,
the output isn't truly ordered the same way. This is not an issue for the
case that I included in the regression test, where the join happens on a
constant, but I can't figure out whether this might be an issue with some
other query.

This code and bug was in 1f4ad703, and it
caused an "operator XXX is not a valid ordering operator" error.

The 'sortop' field in SortClause and GroupClause needs to be an ordering
operator, i.e. the "<" operator, while we use the "=" operator to represent
grouping in other places. Need to be careful to convert between the two
in right places.

Add a few tests for this in the gp_dqa test case. This was reproducible by
the existing queries, when you coerce the planner to choose sort+group
aggregates instead of hash aggregates.