Re: ALTER COLUMN ... SET EXPRESSION to alter stored generated column's expression
От | Peter Eisentraut |
---|---|
Тема | Re: ALTER COLUMN ... SET EXPRESSION to alter stored generated column's expression |
Дата | |
Msg-id | fbc544ee-5c16-dff2-0f74-bcffb0a0aa1d@eisentraut.org обсуждение исходный текст |
Ответ на | Re: ALTER COLUMN ... SET EXPRESSION to alter stored generated column's expression (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>) |
Ответы |
Re: ALTER COLUMN ... SET EXPRESSION to alter stored generated column's expression
|
Список | pgsql-hackers |
On 06.10.23 14:57, Ashutosh Bapat wrote: > On Fri, Oct 6, 2023 at 6:06 PM Peter Eisentraut <peter@eisentraut.org> wrote: >> >> On 28.08.23 11:54, Amul Sul wrote: >>> Thanks for the review comments, I have fixed those in the attached >>> version. In >>> addition to that, extended syntax to have the STORE keyword as suggested by >>> Vik. >> >> An additional comment: When you change the generation expression, you >> need to run ON UPDATE triggers on all rows, if there are any triggers >> defined. That is because someone could have triggers defined on the >> column to either check for valid values or propagate values somewhere >> else, and if the expression changes, that is kind of like an UPDATE. >> >> Similarly, I think we should consider how logical decoding should handle >> this operation. I'd imagine it should generate UPDATE events on all >> rows. A test case in test_decoding would be useful. > > Should we treat it the same fashion as ALTER COLUMN ... TYPE which > rewrites the column values? Of course that rewrites the whole table, > but logically they are comparable. I don't know. What are the semantics of that command with respect to triggers and logical decoding?
В списке pgsql-hackers по дате отправления: