Re: Generated column is not updated (Postgres 13)
От | Tom Lane |
---|---|
Тема | Re: Generated column is not updated (Postgres 13) |
Дата | |
Msg-id | 3795805.1621544948@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Generated column is not updated (Postgres 13) (Vitaly Ustinov <vitaly@ustinov.ca>) |
Список | 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
В списке pgsql-bugs по дате отправления: