[#766] Fix incorrect results if sub query HAVING uses GROUP BY column from another sub query in the outer query FROM/JOIN

Background

• A recent commit d5b3c861 (as part of !1022 (merged)) fixed the #766 (closed) query mentioned in the issue description on gitlab but a similar issue exists when a subquery is used instead of a table in the FROM/JOIN list.

• See below example where instead of FROM customers c in the first query, the second query uses FROM (select * from customers) c. The two usages are identical but the second query output is 5 rows instead of the expected 3 rows.

  OCTO> SELECT ALL c.customer_id FROM customers c WHERE EXISTS (SELECT 1 FROM orders GROUP BY order_id having c.customer_id > 2) GROUP BY customer_id;
  CUSTOMER_ID
  3
  4
  5
  (3 rows)
  OCTO> SELECT ALL c.customer_id FROM (select * from customers) c WHERE EXISTS (SELECT 1 FROM orders GROUP BY order_id having c.customer_id > 2) GROUP BY customer_id;
  CUSTOMER_ID
  1
  2
  3
  4
  5
  (5 rows)

Issue

• d5b3c861 fixed src/m_templates/tmpl_column_reference.ctemplate but the same code is duplicated for the LP_DERIVED_COLUMN case in src/m_templates/tmpl_print_expression.ctemplate and was not fixed then.

Fix

• A new src/m_templates/tmpl_column_reference_common.ctemplate file now has code that is common to both tmpl_column_reference.ctemplate and the LP_DERIVED_COLUMN case of tmpl_print_expression.ctemplate. This is now invoked from both the callers thereby avoiding code duplication.

• Since the common code now has the fix done in d5b3c861, the above issue for the LP_DERIVED_COLUMN case is automatically fixed as part of the code move.

Misc

• Enhanced comments in src/optimization_transforms/lp_replace_derived_table_references.c for why derived_column field is needed.

• Removed code in src/optimization_transforms/lp_generate_xref_keys.c that was long commented out and only likely to be confusing to a future reader.

Test

• The existing test_group_by/TGB14 subtest has been enhanced to verify the fixes in this commit.