From a8f7687a0b8645697b48cc40fd1a73d455d0c1fc Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Sun, 15 Jan 2023 14:06:46 -0500 Subject: 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/nodeModifyTable.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'src/backend/executor/nodeModifyTable.c') diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c index 4c49edef250..5121dff7f5b 100644 --- a/src/backend/executor/nodeModifyTable.c +++ b/src/backend/executor/nodeModifyTable.c @@ -361,7 +361,7 @@ ExecCheckTIDVisible(EState *estate, * (Currently, ri_extraUpdatedCols is consulted only in UPDATE, but we might * as well fill it for INSERT too.) */ -static void +void ExecInitStoredGenerated(ResultRelInfo *resultRelInfo, EState *estate, CmdType cmdtype) -- cgit v1.2.3