aboutsummaryrefslogtreecommitdiff
path: root/src/backend/commands/event_trigger.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2024-03-14 14:57:16 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2024-03-14 14:57:16 -0400
commitb4a71cf65d70b98aaf890b13ec600e340ff69e3f (patch)
tree4ef3a8e2c41649665a80f6c8caa8e517709cfd82 /src/backend/commands/event_trigger.c
parentd1162cfda885c5a8cb9cebfc8eed9f1d76855e83 (diff)
downloadpostgresql-b4a71cf65d70b98aaf890b13ec600e340ff69e3f.tar.gz
postgresql-b4a71cf65d70b98aaf890b13ec600e340ff69e3f.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/commands/event_trigger.c')
0 files changed, 0 insertions, 0 deletions