]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Allow table-qualified variable names in ON CONFLICT ... WHERE.
authorTom Lane <tgl@sss.pgh.pa.us>
Tue, 13 Apr 2021 19:39:33 +0000 (15:39 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 13 Apr 2021 19:39:41 +0000 (15:39 -0400)
commit6c0373ab77359c94b279c4e67c91aa623841af65
treea029c1f45655b7100677c3bdfb33bc197042b04c
parente8c435a824e123f43067ce6f69d66f14cfb8815e
Allow table-qualified variable names in ON CONFLICT ... WHERE.

Previously you could only use unqualified variable names here.
While that's not a functional deficiency, since only the target
table can be referenced, it's a surprising inconsistency with the
rules for partial-index predicates, on which this syntax is
supposedly modeled.

The fix for that is no harder than passing addToRelNameSpace = true
to addNSItemToQuery.  However, it's really pretty bogus for
transformOnConflictArbiter and transformOnConflictClause to be
messing with the namespace item for the target table at all.
It's not theirs to manage, it results in duplicative creations of
namespace items, and transformOnConflictClause wasn't even doing
it quite correctly (that coding resulted in two nsitems for the
target table, since it hadn't cleaned out the existing one).
Hence, make transformInsertStmt responsible for setting up the
target nsitem once for both these clauses and RETURNING.

Also, arrange for ON CONFLICT ... UPDATE's "excluded" pseudo-relation
to be added to the rangetable before we run transformOnConflictArbiter.
This produces a more helpful HINT if someone writes "excluded.col"
in the arbiter expression.

Per bug #16958 from Lukas Eder.  Although I agree this is a bug,
the consequences are hardly severe, so no back-patch.

Discussion: https://postgr.es/m/16958-963f638020de271c@postgresql.org
src/backend/parser/analyze.c
src/backend/parser/parse_clause.c
src/test/regress/expected/insert_conflict.out
src/test/regress/sql/insert_conflict.sql