In INSERT/UPDATE, use the table's real tuple descriptor as target.
authorTom Lane <tgl@sss.pgh.pa.us>
Mon, 26 Oct 2020 15:36:53 +0000 (11:36 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Mon, 26 Oct 2020 15:36:53 +0000 (11:36 -0400)
commit20d3fe9009ddbbbb3da3a2da298f922054b43f8c
tree96af72fc312b8ab26c071b620f271313038d0504
parentfa42c2ecb0f6e89f74bc1cc37b56a1d43e45d513
In INSERT/UPDATE, use the table's real tuple descriptor as target.

Previously, ExecInitModifyTable relied on ExecInitJunkFilter,
and thence ExecCleanTypeFromTL, to build the target descriptor from
the query tlist.  While we just checked (in ExecCheckPlanOutput)
that the tlist produces compatible output, this is not a great
substitute for the relation's actual tuple descriptor that's
available from the relcache.  For one thing, dropped columns will
not be correctly marked attisdropped; it's a bit surprising that
we've gotten away with that this long.  But the real reason for
being concerned with this is that using the table's descriptor means
that the slot will have correct attrmissing data, allowing us to
revert the klugy fix of commit ba9f18abd.  (This commit undoes
that one's changes in trigger.c, but keeps the new test case.)
Thus we can solve the bogus-trigger-tuple problem with fewer cycles
rather than more.

No back-patch, since this doesn't fix any additional bug, and it
seems somewhat more likely to have unforeseen side effects than
ba9f18abd's narrow fix.

Discussion: https://postgr.es/m/16644-5da7ef98a7ac4545@postgresql.org
src/backend/commands/trigger.c
src/backend/executor/execJunk.c
src/backend/executor/nodeModifyTable.c
src/include/executor/executor.h