Re:Re: BUG #17036: generated column cann't modifyed auto when update
| От | 德哥 |
|---|---|
| Тема | Re:Re: BUG #17036: generated column cann't modifyed auto when update |
| Дата | |
| Msg-id | 2e46e6b5.1930.179abb8b6c0.Coremail.digoal@126.com обсуждение исходный текст |
| Ответ на | Re: BUG #17036: generated column cann't modifyed auto when update ("David G. Johnston" <david.g.johnston@gmail.com>) |
| Ответы |
Re: BUG #17036: generated column cann't modifyed auto when update
Re: BUG #17036: generated column cann't modifyed auto when update |
| Список | pgsql-bugs |
The generated column can be used to automatically generate the modified timestamp of a tuple, but PG 12 currently supports this scenario. PG 13 has started to change its behavior, which makes our application need to be modified. This is the first time I have ever seen a PG upgrade kill a nice feature.
--公益是一辈子的事,I'm Digoal,Just Do It.
在 2021-05-27 10:33:40，"David G. Johnston" <david.g.johnston@gmail.com> 写道：
On Wednesday, May 26, 2021, 德哥 <digoal@126.com> wrote:
And immutable function is stable when parameter not change, when parameter changed , the immutable function will recall and recompute.but in PG 13 and PG 14 , it is also wrong.```create or replace function im_now (anyelement) returns timestamptz as $$select now();$$ language sql strict immutable;create table t1 (id int primary key, c1 int, info text, crt_time timestamp,mod_time timestamp GENERATED ALWAYS AS (im_now(t1)) stored);This seems to be related to this already reported bug (the similar one I noted in my other reply).David J.
В списке pgsql-bugs по дате отправления: