This commit adds partitioned indexes from upstream Postgres. This commit is
mostly cherry-picked from Postgres 11 and bug fixes from Postgres 12.

Differences from upstream:
 - Postgres has two additional relkind's - RELKIND_PARTITIONED_TABLE and
   RELKIND_PARTITIONED_INDEX, which have no on disk storage. Greenplum does not
   have these additional relkinds. Thus, partitioned indexes have physical
   storage.
 - CREATE INDEX ON ONLY <table> DDL has not yet been implemented
 - ALTER INDEX ATTACH PARTITION DDL has not yet been implemented

Constraint changes:
 - Constraints and their backing index have the same names. Thus, partitions of
   a table no longer share the same constraint name, and are instead related to
   their parent via INTERNAL_AUTO dependencies.

Index changes:
 - Child partition indexes can no longer be directly dropped, and must be
   dropped from their root. This includes mid-level and leaf indexes.
 - Adding indexes to mid-level partitions cascade to their children.

These changes are mostly cherry-picked from:
commit 8b08f7d4
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Date:   Fri Jan 19 11:49:22 2018 -0300

    Local partitioned indexes

    When CREATE INDEX is run on a partitioned table, create catalog entries
    for an index on the partitioned table (which is just a placeholder since
    the table proper has no data of its own), and recurse to create actual
    indexes on the existing partitions; create them in future partitions
    also.

    As a convenience gadget, if the new index definition matches some
    existing index in partitions, these are picked up and used instead of
    creating new ones.  Whichever way these indexes come about, they become
    attached to the index on the parent table and are dropped alongside it,
    and cannot be dropped on isolation unless they are detached first.

    To support pg_dump'ing these indexes, add commands
        CREATE INDEX ON ONLY <table>
    (which creates the index on the parent partitioned table, without
    recursing) and
        ALTER INDEX ATTACH PARTITION
    (which is used after the indexes have been created individually on each
    partition, to attach them to the parent index).  These reconstruct prior
    database state exactly.

    Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
            Langote, Jesper Pedersen, Simon Riggs, David Rowley
    Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql

Changes were also cherry-picked from the following Postgres commits:
  eb7ed3f3 - Allow UNIQUE indexes on partitioned tables
  ae366aa5 - Detach constraints when partitions are detached
  19184fcc - Simplify coding to detach constraints when detaching partition
  c7d43c4d - Correct attach/detach logic for FKs in partitions
  17f206fb - Set pg_class.relhassubclass for partitioned indexes
Co-authored-by: NKalen Krempely <kkrempely@pivotal.io>

When altering a partitioned table and adding an incorrectly specified
partition, an assertion was hit rather than gracefully erroring out.
Make sure that the requested partition matches the underlying table
definition before continuing down into the altering code. This also
adds a testcase for this.

Reported-by: Kalen Krempely in #6967
Reviewed-by: NPaul Guo <pguo@pivotal.io>
Reviewed-by: NGeorgios Kokolatos <gkokolatos@pivotal.io>

Pull from upstream Postgres to make DefineIndex recursively create partitioned
indexes. Instead of creating an individual IndexStmt for every partition,
create indexes by recursing on the partition children.  This aligns index
creation with upstream in preparation for adding INTERNAL_AUTO relationships
between partition indexes.

 * The QD will now choose the same name for partition indexes as Postgres.
 * Update tests to reflect the partition index names changes.
 * The changes to DefineIndex are mostly cherry-picked from Postgres commit:
   8b08f7d4
 * transformIndexStmt and its callers have been aligned with Postgres
   REL9_4_STABLE
Co-authored-by: NKalen Krempely <kkrempely@pivotal.io>

This is in preparation for adding operator classes as a new column
(distclass) to gp_distribution_policy. This naming is consistent with
pg_index.indkey/indclass. Change the datatype to int2vector, also for
consistency with pg_index, and some other catalogs that store attribute
numbers, and because int2vector is slightly more convenient to work with
in the backend. Move the column to the end of the table, so that all the
variable-length and nullable columns are at the end, which makes it
possible to reference the other columns directly in Form_gp_policy.

Add a backend function, pg_get_table_distributedby(), to deparse the
DISTRIBUTED BY definition of a table into a string. This is similar to
pg_get_indexdef_columns(), pg_get_functiondef() etc. functions that we
have. Use the new function in psql and pg_dump, when connected to a GPDB6
server.
Co-authored-by: NHeikki Linnakangas <hlinnakangas@pivotal.io>
Co-authored-by: NPeifeng Qiu <pqiu@pivotal.io>
Co-authored-by: NAdam Lee <ali@pivotal.io>

We cleared the local 'useHeapMultiInsert' variable, as soon as we saw
at least one AO partition, even if we had already buffered tuples for
a heap partition earlier. As a result, we didn't flush the multi-insert
buffer at the end of the COPY.

Fixes https://github.com/greenplum-db/gpdb/issues/6678Reviewed-by: NAdam Lee <ali@pivotal.io>

The Greenplum specific error handling via ereport()/elog() calls was
in need of a unification effort as some parts of the code was using a
different messaging style to others (and to upstream). This aims at
bringing many of the GPDB error calls in line with the upstream error
message writing guidelines and thus make the user experience of
Greenplum more consistent.

The main contributions of this patch are:

* errmsg() messages shall start with a lowercase letter, and not end
  with a period. errhint() and errdetail() shall be complete sentences
  starting with capital letter and ending with a period. This attempts
  to fix this on as many ereport() calls as possible, with too detailed
  errmsg() content broken up into details and hints where possible.

* Reindent ereport() calls to be more consistent with the common style
  used in upstream and most parts of Greenplum:

	ereport(ERROR,
			(errcode(<CODE>),
			 errmsg("short message describing error"),
			 errhint("Longer message as a complete sentence.")));

* Avoid breaking messages due to long lines since it makes grepping
  for error messages harder when debugging. This is also the de facto
  standard in upstream code.

* Convert a few internal error ereport() calls to elog(). There are
  no doubt more that can be converted, but the low hanging fruit has
  been dealt with. Also convert a few elog() calls which are user
  facing to ereport().

* Update the testfiles to match the new messages.

Spelling and wording is mostly left for a follow-up commit, as this was
getting big enough as it was. The most obvious cases have been handled
but there is work left to be done here.

Discussion: https://github.com/greenplum-db/gpdb/pull/6378Reviewed-by: NAshwin Agrawal <aagrawal@pivotal.io>
Reviewed-by: NHeikki Linnakangas <hlinnakangas@pivotal.io>

Melanie pointed out that there is no existing test for this scenario.
Also expand the comment in the code to explain this scenario.

I think this is more clear. Now that we the error position is displayed
with the error, we don't need to work so hard to deparse the value and the
partition type. The error position makes that clear.

This came up during the 9.3 merge. Passing InvalidOid to
deparse_context_for() will no longer work in 9.3, so we'd need to change
this somehow in the 9.3 merge, anyway.

This commit changed the way the grammar was parsing the subpartition
information to ensure that the templates could not exist without a
`SUBPARTITION BY`.

Testing coverage for the case where the `SUBPARTITION TEMPLATE`
expression is written before a `SUBPARTITION BY` was added.

The error displayed when the template appeared after a Partition was
changed to point to the TEMPLATE
Co-authored-by: NEkta Khanna <ekhanna@pivotal.io>
Co-authored-by: NJesse Zhang <sbjesse@gmail.com>
Co-authored-by: NAdam Berlin <aberlin@pivotal.io>

NULLs are not allowed in the PARTITION START or END clauses, but the checks
for NULLs were performed only after sorting the list of partitions. The
sort function did not consider the possibility of NULLs, and would therefore
pass NULLs to comparison functions, even if they're marked as strict. That
could cause a segfault.

Fixes https://github.com/greenplum-db/gpdb/issues/5503

Non-leaf heap partition tables and their auxiliary tables
(aoseg/toast/...) are exempt from age computations.  The test validates
that auxiliary tables of partitioned table are created with relfrozenxid
= 0.
Co-authored-by: NDavid Kimura <dkimura@pivotal.io>

This reverts commit 4750e1b6.

This is the final batch of commits from PostgreSQL 9.2 development,
up to the point where the REL9_2_STABLE branch was created, and 9.3
development started on the PostgreSQL master branch.

Notable upstream changes:

* Index-only scan was included in the batch of upstream commits. It
  allows queries to retrieve data only from indexes, avoiding heap access.

* Group commit was added to work effectively under heavy load. Previously,
  batching of commits became ineffective as the write workload increased,
  because of internal lock contention.

* A new fast-path lock mechanism was added to reduce the overhead of
  taking and releasing certain types of locks which are taken and released
  very frequently but rarely conflict.

* The new "parameterized path" mechanism was added. It allows inner index
  scans to use values from relations that are more than one join level up
  from the scan. This can greatly improve performance in situations where
  semantic restrictions (such as outer joins) limit the allowed join orderings.

* SP-GiST (Space-Partitioned GiST) index access method was added to support
  unbalanced partitioned search structures. For suitable problems, SP-GiST can
  be faster than GiST in both index build time and search time.

* Checkpoints now are performed by a dedicated background process. Formerly
  the background writer did both dirty-page writing and checkpointing. Separating
  this into two processes allows each goal to be accomplished more predictably.

* Custom plan was supported for specific parameter values even when using
  prepared statements.

* API for FDW was improved to provide multiple access "paths" for their tables,
  allowing more flexibility in join planning.

* Security_barrier option was added for views to prevents optimizations that
  might allow view-protected data to be exposed to users.

* Range data type was added to store a lower and upper bound belonging to its
  base data type.

* CTAS (CREATE TABLE AS/SELECT INTO) is now treated as utility statement. The
  SELECT query is planned during the execution of the utility. To conform to
  this change, GPDB executes the utility statement only on QD and dispatches
  the plan of the SELECT query to QEs.
Co-authored-by: NAdam Lee <ali@pivotal.io>
Co-authored-by: NAlexandra Wang <lewang@pivotal.io>
Co-authored-by: NAshwin Agrawal <aagrawal@pivotal.io>
Co-authored-by: NAsim R P <apraveen@pivotal.io>
Co-authored-by: NDaniel Gustafsson <dgustafsson@pivotal.io>
Co-authored-by: NGang Xiong <gxiong@pivotal.io>
Co-authored-by: NHaozhou Wang <hawang@pivotal.io>
Co-authored-by: NHeikki Linnakangas <hlinnakangas@pivotal.io>
Co-authored-by: NJesse Zhang <sbjesse@gmail.com>
Co-authored-by: NJinbao Chen <jinchen@pivotal.io>
Co-authored-by: NJoao Pereira <jdealmeidapereira@pivotal.io>
Co-authored-by: NMelanie Plageman <mplageman@pivotal.io>
Co-authored-by: NPaul Guo <paulguo@gmail.com>
Co-authored-by: NRichard Guo <guofenglinux@gmail.com>
Co-authored-by: NShujie Zhang <shzhang@pivotal.io>
Co-authored-by: NTaylor Vesely <tvesely@pivotal.io>
Co-authored-by: NZhenghua Lyu <zlv@pivotal.io>

Root partition and internal parent partitions do not contain any data. But since
currently these tables still have valid relfrozenxid, their age keeps
growing. The problem it poses is to bring the age down need to run vacuum on
root, which trickles down and vacuum's each and every child partition as
well. Instead if only leaf if getting modified those can be vacuumed in
isolation and bring the age down and avoid overhead of vacuuming the full
hierarchy.

So, similar to AO, CO, external tables, etc.. for root and parent partitions
record relfrozenxid as 0 (InvalidTransaction) during table creation. This works
since these tables will never store any xids. This would skip them from age
calculation hence eliminate forced need for vacuum on them. Ideally same can be
achieved by defining root and internal parent partition as AO tables but its lot
more work and ddls need modifications.

As part of the Postgres 8.3 merge, all heap tables now automatically
create an array type. The array type will usually be created with
typname '_<heap_name>' since the automatically created composite type
already takes the typname '<heap_name>' first. If typname
'_<heap_name>' is taken, the logic will continue to prepend
underscores until no collision (truncating the end if typname gets
past NAMEDATALEN of 64). This might be an oversight in upstream
Postgres since certain scenarios involving creating a large number of
heap tables with similar names could result in a lot of typname
collisions until no heap tables with similar names can be
created. This is very noticable in Greenplum heap partition tables
because Greenplum has logic to automatically name child partitions
with similar names instead of having the user name each child
partition.

To prevent typname collision failures when creating a heap partition
table with a large number of child partitions, we will now stop
automatically creating the array type for child partitions.

References:
https://www.postgresql.org/message-id/flat/20070302234016.GF3665%40fetter.org
https://github.com/postgres/postgres/commit/bc8036fc666a8f846b1d4b2f935af7edd90eb5aa

Commit ce3153fa, about to be merged from PostgreSQL 9.0 soon, removes
the -w option from pg_regress's "diff" invocation. That commit will fix
all the PostgreSQL regression tests to pass without it, but we need to
also fix all the GPDB tests. That's what this commit does.

I did much of this in commit 06a2bb64, but now that we're about to
actually merge that, more cases popped up.

Co-Author: Daniel Gustafsson <dgustafsson@pivotal.io>

Commit ce3153fa, about to be merged from PostgreSQL 9.0 soon, removes
the -w option from pg_regress's "diff" invocation. That commit will fix
all the PostgreSQL regression tests to pass without it, but we need to
also fix all the GPDB tests. That's what this commit does.

Since ICW is a very longrunning process, attempt to reduce time
consumption by reducing overhead during testing while keeping the
test constant (coverage not reduced).

Avoid dropping/recreating underlying test tables when not required,
reduce the number of partitions in some cases and skip pointless
drops for objects we know doesn't exist. In total this shaves about
30-40 seconds off an ICW run on my local machine, mileage may vary.

Make sure that we are able to exchnage in an external partition, and
also ensure that truncation doesn't recurse into the ext partition.

The ao_ptotal() test function was broken a long time ago, in the 8.3 merge,
by the removal of implicit cast from text to integer. You just got an
"operator does not exist: text > integer" error. However, the queries
using the function were inside start/end_ignore blocks, so that didn't

We have tests on tupcount elsewhere, in the uao_* tests, for example.
Whether the table is partitioned or not doesn't seem very interesting. So
just remove the test queries, rather than try to fix them. (I don't
understand what the endianess issue mentioned in the comment might've
been.)

I kept the test on COPY with REJECT LIMIT on partitioned table. I'm not
sure how interesting that is either, but it wasn't broken. While at it,
I reduced the number of partitions used, though, to shave off a few
milliseconds from the test.

Instead of throwing a NOTICE on every object/role combination, track
whether anything at all was revoked, and only issue one NOTICE for the
whole command, if nothing was revoked. This reduces the noise if the REVOKE
lists multiple objects and/or roles.

This refactoring makes it easier to carry this diff vs. upstream, as we
merge the column-level permissions feature from upstream.

Discussion: https://groups.google.com/a/greenplum.org/d/msg/gpdb-dev/Ttn_UJb4Otg/LS1cFrDiAwAJ

Hash partitioning was never fully implemented, and was never turned
on by default. There has been no effort to complete the feature, so
rather than carrying dead code this removes all support for hash
partitioning. Should we ever want this feature, we will most likely
start from scratch anyways.

As an effect from removing the unsupported MERGE/MODIFY commands,
this previously accepted query is no longer legal:

	create table t (a int, b int)
	distributed by (a)
	partition by range (b) (start () end(2));

The syntax was an effect of an incorrect rule in the parser which
made the start boundary optional for CREATE TABLE when it was only
intended for MODIFY PARTITION.

pg_upgrade was already checking for hash partitions so no new check
was required (upgrade would've been impossible anyways due to hash
algorithm change).

Running ALTER TABLE PARTITION SPLIT on range subpartitions results in both new
partitions to incorrectly have the same partition order value (parruleord in
pg_partition_rule). ALTER TABLE PARTITION SPLIT is accomplished by running
multiple DDLs in sequence:

  1. CREATE TEMP TABLE to match the data type/orientation of the partition we are
     splitting

  2. ALTER TABLE PARTITION EXCHANGE the partition with the new temporary table.
     The temporary table now contains the partition data, and the partition
     table is now empty.

  3. ALTER TABLE DROP PARTITION on the exchanged partition (the new empty table)

  3a. Drop the partitioning rule on the empty partition

  3b. DROP TABLE on the empty partition

At this point (in the old behavior) we remove the partition rule from the in
memory copy of the partition metadata. We need to remove it from the context
here or ADD PARTITION will believe that a partition for the split range already
exists, and will fail to create a new partition.

Now, create two new partitions in the place of the old one. For each partition:

  4a. CREATE TABLE for the new range

  4b. ADD PARTITION - Search for a hole in the partition order to place the
      partition. Open up a hole in the parruleord if needed.

When adding a subpartition, ADD PARTITION relies on the partition rules passed
to it in order to find any holes in the partition range. Previously, the
metadata was not refreshed when adding the second partition, and this resulted
in the ADD PARTITION command creating both tables with the same partition rule
order (parruleord). This commit resolves the issue by refreshing the partition
metadata (PgPartRule) passed to the CREATE TABLE/ADD PARTITION commands upon
each iteration.

The storage/basic/partition tests were a collection of bugfixes from
primarily older version of Greenplum. This moves the valuable tests
over to ICW and removes the ones which are already covered in existing
ICW suites. The decision for each individual tests is elaborated on in
the list below:

* MPP-3379 was testing an ancient bug and MPP-3553 a hypothetical
  bug from before the current partition code was written. Combined
  the two since the added clause will still cover the ancient 3379
  issue and remove the other from Tinc.

* MPP-3625 was mostly already covered by existing tests in partition
  and bfv_partition. Added a test for splitting a non-existing default
  as that was the only thing covered.

* MPP-6297 is testing the pg_get_partition_def() function after the
  partition hierarchy has been amended via ALTER TABLE, which is
  already covered by the partition suite. Additionally it tested
  running pg_dump, which use pg_get_partition_def() heavily, and
  this is covered by our pg_upgrade tests.

* MPP-6379 tested that partitions inherited unique indexes, the test
  was moved to the partition_indexing suite.

* MPP-6489 tested ALTER TABLE .. SET DISTRIBUTED BY for subpartitions
  which didn't seem covered in ICW so moved to alter_distribution_policy
  suite

* MPP-7661 tested for an old bug where pg_dump incorrectly handled
  partition hierarchies created with the EVERY syntax. pg_upgrade
  tests in ICW will run this test on hierarchies from the partition
  suites so remove.

* MPP-7734 tested for excessive memory consumption in the case of a
  very deep partitioning hierarchy. The issue in question was fixed
  in 4.0 and the test clocks in at ~ 1.5 minutes, so remove the test
  to save time in the test pipeline. The test was more of a stress
  test than a regression test at this point, and while thats not of
  no importance, we should run stresstests deliberately and not
  accidentally.

* MPP-6537/6538 tested that new partitions introduced in the hierarchy
  correctly inherited the original owner. Test moved to the partition
  suite.

* MPP-7002 tested that splitting partitions worked after a column
  had been dropped. Since we had a similar test already in the
  partition suite, extend that test to also cover splitting.

* MPP-7164 is testing for partition rank after DDL operations on the
  partition hierarchy. I can see that we are testing something along
  the lines of this in ICW so pulled it across. In the process, fixed
  the test to actually run the SQL properly and not error out on a
  syntax error. Also removed a duplicated file for setting up the views.

* MPP-9548 tested for the case of insert data into a column which
  was dropped and then re-added. Since we already had that covered
  in the partition suite, simply extended the comment on that case
  and added another projection to really cover it completely.

* MPP-7232 tests that pg_get_partition_def() supports renamed partitions
  correctly. Added to ICW but the pg_dump test removed.

* MPP-17740 tested the .. WITH (tablename = <t> ..) syntax which we
  to some extent already covered, but added a separate case to test
  permutations of it.

* MPP-18673 covers an old intermittent bug where concurrent sessions
  splitting partitions would corrupt the relcache. The test in Tinc
  didn't however run concurrently so the underlying bug wasn't being
  tested, so remove the test. If we want a similar test at some point
  it should be an isolationtester suite.

* MPP-17761 tests an old bug where splitting an added CO partition
  failed. Since we didn't have much in terms of testing splitting
  CO, extended the block doing split testing with that.

* MPP-17707-* were essentially the same test but with varying storage
  options. While a lot of this is covered elsehwere, these tests were
  really easy to read so rolled them all into a new suite called
  partition_storage.

* MPP-12775 covered yet another split/exchange scenario. Added a
  short variant to the partition suite.

* MPP-17110 tests for an old regression in attribute encoding for
  added columns in partitioning hierarchies. Removed the part of
  the test that checked compression ratio as AO compression should
  be tested elsewhere.

* The partition_ddl2 test was moved over as partition_ddl more or
  less unchanged.

This also removes unused answer files mpp8031.ans.orca and query99
for which there were no corresponding tests, as well as the data
file used for copying data into the tests (a copy of which already
exists in src/test/regress/data).

Partition exchange for a partition table with sub-partitions should
throw an error as soon as the incompatability is schemas between the
partition table and the candidate table to exchange is found.
Signed-off-by: NJesse Zhang <sbjesse@gmail.com>

I'm not sure we need all of these, but let's at least move them into the
main regression suite. I did leave out a few queries that were identical to
existing tests that I spotted, and merged a few that were almost identical.

The old mechanism was to scan the complete plan, searching for a pattern
with a Join, where the outer side included an Append node. The inner
side was duplicated into an InitPlan, with the pg_partition_oid aggregate
to collect the Oids of all the partitions that can match. That was
inefficient and broken: if the duplicated plan was volatile, you might
choose wrong partitions. And scanning the inner side twice can obviously
be slow, if there are a lot of tuples.

Rewrite the way such plans are generated. Instead of using an InitPlan,
inject a PartitionSelector node into the inner side of the join.

Fixes github issues #2100 and #2116.

The loop to print each constraint's name was broken: it printed the name of
the first constraint multiple times. A test case, as matter of principle.

In the passing, change the set of tests around this error to all use the
same partitioned table, rather than drop and recreate it for each command.
And reduce the number of partitions from 10 to 5. Shaves some milliseconds
from the time to run the test.

And remove the rest of old partition_exchange TINC test. We already had
tests in 'partition' test file, for validating that the values in the
exchanged table are valid for the partition (search for "-- validation").

There were also tests for exchanging a partition in a hash partitioned
table, but the validation hasn't apparently been implemented for hash
partitions, and they're not supported anyway, so that doesn't seem very
interesting to test.

Rename the test tables in 'partition' test, so that they don't clash with
the test tables in 'partition1' test. Change a few validation queries to
not get confused if there are unrelated tables with partitions in the
database. With these changes, we can run 'partition' and 'partition1' in
the same parallel group, which is a more logical grouping.

All of these tests were already in the 'partition' test of the main suite,
in more or less identical form.

I did add one little query to 'partition', to test that START of a partition
range cannot be NULL. The existing test only covered "END (NULL)".

Also, stop testing for long-gone scripts gpaddpart, gpcreatepart and
gpdeletepart utilities.

The different kinds of NOTICE messages regarding table distribution
were using a mix of upper and lower case for 'DISTRIBUTED BY'. Make
them consistent by using upper case for all messages and update the
test files, and atmsort regexes, to match.

The fix removes the assumption that no other partition table exists before the
test starts.

    When we execute an ALTER TABLE statement that splits default partition into a "New" and a new Default partition, we perform the following 5 steps:

     * copy the tuples located in the default partition into a temporary table,
     * drop default partition,
     * create the “New“ partition,
     * create the new DEFAULT partition, and
     * copy all tuples from the temporary table into the newly created partitions.

    The last step is executed in split_rows, where for each tuple in the temporary table,

     * we determine the target partition/table,
     * construct the slot of the target table (if is NULL), and
     * store the tuple into the target table.

    Currently, we allocate the tuple table slot of the target table into a per-tuple memory context. If the size of that memory context exceeds 50KB, then we reset it. This will cause issues, since it will free target table's slot and at the next iteration (copy the next tuple) we will try to access the attributes of a freed (and not NULL) slot. In addition, the target table slot lifespan is much longer than an individual tuple. So it is not correct to allocate the slot in a per-tuple memory context.

    To solve this issue, we allocate target's tuple table slot in PortalHeapMemory. This is the CurrentMemoryContext that is used in split_rows before we start copying tuples. PortalHeapMemory is used already for storing the tuple table slot of the temporary table and the ResultRelInfo of the target tables. PortalHeapMemory is not freed while we copy tuples. After copying all tuples to the new partitions, we drop target tables' slots.
Signed-off-by: NNikos Armenatzoglou <nikos.armenatzoglou@gmail.com>

This is a partial backport of a larger body of work which also already have
been partially backported.

Remove the GPDB-specific "breadcrumbs" mechanism from the parser. It is
made obsolete by the upstream mechanism. We lose context information from
a few errors, which is unfortunate, but seems acceptable. Upstream doesn't
have context information for those errors either.

The backport was originally done by Daniel Gustafsson, on top of the
PostgreSQL 8.3 merge. I tweaked it to apply it to master, before the
merge.

Upstream commit:

  commit b153c092
  Author: Tom Lane <tgl@sss.pgh.pa.us>
  Date:   Mon Sep 1 20:42:46 2008 +0000

    Add a bunch of new error location reports to parse-analysis error messages.
    There are still some weak spots around JOIN USING and relation alias lists,
    but most errors reported within backend/parser/ now have locations.

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.

Currently, the error reporting for duplicate key value violation for unique
indexes does not contain useful information for users when debugging. This
commit backports two commits from PostgreSQL (shown below) and updates our
multikey tuplesort to use the same. Now the error will display the first
instance of a duplicate key violation.

Authors: Jimmy Yih and Abhijit Subramanya

commit b680ae4b
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Sat Aug 1 19:59:41 2009 +0000

    Improve unique-constraint-violation error messages to include the exact
    values being complained of.

    In passing, also remove the arbitrary length limitation in the similar
    error detail message for foreign key violations.

    Itagaki Takahiro

 Conflicts:
	contrib/citext/expected/citext.out
	contrib/citext/expected/citext_1.out
	src/backend/access/common/indextuple.c
	src/backend/access/index/genam.c
	src/backend/access/nbtree/nbtinsert.c
	src/backend/utils/adt/ri_triggers.c
	src/backend/utils/adt/ruleutils.c
	src/include/access/genam.h
	src/include/access/itup.h
	src/include/utils/builtins.h
	src/test/regress/expected/alter_table.out
	src/test/regress/expected/arrays.out
	src/test/regress/expected/create_index.out
	src/test/regress/expected/plpgsql.out
	src/test/regress/expected/transactions.out
	src/test/regress/expected/uuid.out
	src/test/regress/output/constraints.source
	src/test/regress/output/tablespace.source

commit 527f0ae3
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Sat Aug 1 20:59:17 2009 +0000

    Department of second thoughts: let's show the exact key during unique index
    build failures, too.  Refactor a bit more since that error message isn't
    spelled the same.

 Conflicts:
	src/backend/access/nbtree/nbtinsert.c
	src/backend/utils/sort/tuplesort.c
	src/test/regress/expected/alter_table.out
	src/test/regress/expected/create_index.out