Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.

The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint.  DO NOTHING avoids the
constraint violation, without touching the pre-existing row.  DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed.  The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.

This feature is often referred to as upsert.

This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert.  If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made.  If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.

To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.

Bumps catversion as stored rules change.

Author: Peter Geoghegan, with significant contributions from Heikki
    Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
    Dean Rasheed, Stephen Frost and many others.

doc/src/sgml/trigger.sgml

@@ -40,14 +40,17 @@
     On tables and foreign tables, triggers can be defined to execute either
     before or after any <command>INSERT</command>, <command>UPDATE</command>,
     or <command>DELETE</command> operation, either once per modified row,
-    or once per <acronym>SQL</acronym> statement.
-    <command>UPDATE</command> triggers can moreover be set to fire only if
-    certain columns are mentioned in the <literal>SET</literal> clause of the
-    <command>UPDATE</command> statement.
-    Triggers can also fire for <command>TRUNCATE</command> statements.
-    If a trigger event occurs, the trigger's function is called at the
-    appropriate time to handle the event.  Foreign tables do not support the
-    TRUNCATE statement at all.
+    or once per <acronym>SQL</acronym> statement.  If an
+    <command>INSERT</command> contains an <literal>ON CONFLICT DO UPDATE</>
+    clause, it is possible that the effects of a BEFORE insert trigger and
+    a BEFORE update trigger can both be applied together, if a reference to
+    an <varname>EXCLUDED</> column appears.  <command>UPDATE</command>
+    triggers can moreover be set to fire only if certain columns are
+    mentioned in the <literal>SET</literal> clause of the
+    <command>UPDATE</command> statement.  Triggers can also fire for
+    <command>TRUNCATE</command> statements.  If a trigger event occurs,
+    the trigger's function is called at the appropriate time to handle the
+    event.  Foreign tables do not support the TRUNCATE statement at all.
    </para>
 
    <para>
@@ -118,6 +121,35 @@
     be operated on.
    </para>
 
+   <para>
+    If an <command>INSERT</command> contains an <literal>ON CONFLICT
+    DO UPDATE</> clause, it is possible that the effects of all
+    row-level <literal>BEFORE</> <command>INSERT</command> triggers
+    and all row-level BEFORE <command>UPDATE</command> triggers can
+    both be applied in a way that is apparent from the final state of
+    the updated row, if an <varname>EXCLUDED</> column is referenced.
+    There need not be an <varname>EXCLUDED</> column reference for
+    both sets of BEFORE row-level triggers to execute, though.  The
+    possibility of surprising outcomes should be considered when there
+    are both <literal>BEFORE</> <command>INSERT</command> and
+    <literal>BEFORE</> <command>UPDATE</command> row-level triggers
+    that both affect a row being inserted/updated (this can still be
+    problematic if the modifications are more or less equivalent if
+    they're not also idempotent).  Note that statement-level
+    <command>UPDATE</command> triggers are executed when <literal>ON
+    CONFLICT DO UPDATE</> is specified, regardless of whether or not
+    any rows were affected by the <command>UPDATE</command> (and
+    regardless of whether the alternative <command>UPDATE</command>
+    path was ever taken).  An <command>INSERT</command> with an
+    <literal>ON CONFLICT DO UPDATE</> clause will execute
+    statement-level <literal>BEFORE</> <command>INSERT</command>
+    triggers first, then statement-level <literal>BEFORE</>
+    <command>UPDATE</command> triggers, followed by statement-level
+    <literal>AFTER</> <command>UPDATE</command> triggers and finally
+    statement-level <literal>AFTER</> <command>INSERT</command>
+    triggers.
+   </para>
+
    <para>
     Trigger functions invoked by per-statement triggers should always
     return <symbol>NULL</symbol>. Trigger functions invoked by per-row