Re: Generated column is not updated (Postgres 13)
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Vitaly Ustinov <vitaly@ustinov.ca>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
pgsql-bugs@lists.postgresql.org,
"David G. Johnston" <david.g.johnston@gmail.com>
Date: 2021-05-20T21:09:08Z
Lists: pgsql-bugs
Vitaly Ustinov <vitaly@ustinov.ca> writes: > In a BEFORE trigger (PL/pgSQL) I can access not yet computed generated > columns via the "NEW" whole-row var. I can read from it (NULL), and I > can write to it, but the assigned value will be ignored. NEW is not really a whole-row var in the sense that we're discussing here. In any case, yes, nodeModifyTable runs computation of generated columns after firing BEFORE triggers. I suppose that's to prevent the triggers from interfering with those values. > Is it okay with you that the patch 0002 introduces some inconsistency with that? In what way would this introduce (new) inconsistency? I didn't move the computation of those values from where they were. Moreover, so far as I can see, ATRewriteTable doesn't fire BEFORE triggers at all. BTW, while looking around nodeModifyTable, I noted some other gaps in our support for "tableoid" in GENERATED expressions: the FDW code paths in ExecInsert and ExecUpdate fail to fill tts_tableOid till after running ExecComputeStoredGenerated. So they have the same bug that 0001 fixes in ATRewriteTable. It can be fixed the same way, ie move the code that fills tts_tableOid; but I remain very concerned about how many other gaps there are. regards, tom lane
Commits
-
Disallow whole-row variables in GENERATED expressions.
- 61feb8670824 12.8 landed
- 849c7971d1ab 13.4 landed
- 4b10074453d1 14.0 landed
-
Fix usage of "tableoid" in GENERATED expressions.
- dfe51ffbe78a 12.8 landed
- 77e3204ecbf1 13.4 landed
- 2b0ee126bbf0 14.0 landed