]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Make new GENERATED-expressions code more bulletproof.
authorTom Lane <tgl@sss.pgh.pa.us>
Sun, 15 Jan 2023 19:06:46 +0000 (14:06 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Sun, 15 Jan 2023 19:06:46 +0000 (14:06 -0500)
commita8b88c26f7061689ef1aea1b8fd234fed8e1fc9e
tree2f2a3a679c40aa750531d30affaeaadfdc2b2d14
parent547e60b8317e3c351900c650988327b73cf7ae33
Make new GENERATED-expressions code more bulletproof.

In commit 8bf6ec3ba I assumed that no code path could reach
ExecGetExtraUpdatedCols without having gone through
ExecInitStoredGenerated.  That turns out not to be the case in
logical replication: if there's an ON UPDATE trigger on the target
table, trigger.c will call this code before anybody has set up its
generated columns.  Having seen that, I don't have a lot of faith in
there not being other such paths.  ExecGetExtraUpdatedCols can call
ExecInitStoredGenerated for itself, as long as we are willing to
assume that it is only called in CMD_UPDATE operations, which on
the whole seems like a safer leap of faith.

Per report from Vitaly Davydov.

Discussion: https://postgr.es/m/d259d69652b8c2ff50e14cda3c236c7f@postgrespro.ru
src/backend/executor/execUtils.c
src/backend/executor/nodeModifyTable.c
src/include/executor/nodeModifyTable.h
src/test/subscription/t/011_generated.pl