diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2024-03-14 14:57:16 -0400 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2024-03-14 14:57:16 -0400 |
| commit | 82c87af7a0ac97ec6e99277f2deb4ee55e347e1e (patch) | |
| tree | ccb704c073ab395104239d4f329ffdcd921303bd /src/backend/parser/parse_target.c | |
| parent | dc1503d5b8b3a1565702dd13e8874f74211a8e09 (diff) | |
| download | postgresql-82c87af7a0ac97ec6e99277f2deb4ee55e347e1e.tar.gz postgresql-82c87af7a0ac97ec6e99277f2deb4ee55e347e1e.zip | |
Make INSERT-from-multiple-VALUES-rows handle domain target columns.
Commit a3c7a993d fixed some cases involving target columns that are
arrays or composites by applying transformAssignedExpr to the VALUES
entries, and then stripping off any assignment ArrayRefs or
FieldStores that the transformation added. But I forgot about domains
over arrays or composites :-(. Such cases would either fail with
surprising complaints about mismatched datatypes, or insert unexpected
coercions that could lead to odd results. To fix, extend the
stripping logic to get rid of CoerceToDomain if it's atop an ArrayRef
or FieldStore.
While poking at this, I realized that there's a poorly documented and
not-at-all-tested behavior nearby: we coerce each VALUES column to
the domain type separately, and rely on the rewriter to merge those
operations so that the domain constraints are checked only once.
If that merging did not happen, it's entirely possible that we'd get
unexpected domain constraint failures due to checking a
partially-updated container value. There's no bug there, but while
we're here let's improve the commentary about it and add some test
cases that explicitly exercise that behavior.
Per bug #18393 from Pablo Kharo. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/18393-65fedb1a0de9260d@postgresql.org
Diffstat (limited to 'src/backend/parser/parse_target.c')
| -rw-r--r-- | src/backend/parser/parse_target.c | 18 |
1 files changed, 16 insertions, 2 deletions
diff --git a/src/backend/parser/parse_target.c b/src/backend/parser/parse_target.c index 43a7efeebed..9841894d78c 100644 --- a/src/backend/parser/parse_target.c +++ b/src/backend/parser/parse_target.c @@ -813,7 +813,16 @@ transformAssignmentIndirection(ParseState *pstate, fstore->fieldnums = list_make1_int(attnum); fstore->resulttype = baseTypeId; - /* If target is a domain, apply constraints */ + /* + * If target is a domain, apply constraints. Notice that this + * isn't totally right: the expression tree we build would check + * the domain's constraints on a composite value with only this + * one field populated or updated, possibly leading to an unwanted + * failure. The rewriter will merge together any subfield + * assignments to the same table column, resulting in the domain's + * constraints being checked only once after we've assigned to all + * the fields that the INSERT or UPDATE means to. + */ if (baseTypeId != targetTypeId) return coerce_to_domain((Node *) fstore, baseTypeId, baseTypeMod, @@ -943,7 +952,12 @@ transformAssignmentSubscripts(ParseState *pstate, subscripts, rhs); - /* If target was a domain over container, need to coerce up to the domain */ + /* + * If target was a domain over container, need to coerce up to the domain. + * As in transformAssignmentIndirection, this coercion is premature if the + * query assigns to multiple elements of the container; but we'll fix that + * during query rewrite. + */ if (containerType != targetTypeId) { Oid resulttype = exprType(result); |