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  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: BUG #17036: generated column cann't modifyed auto when update  ("David G. Johnston" <david.g.johnston@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: 德哥
Дата:
Сообщение: Re:Re: BUG #17036: generated column cann't modifyed auto when update
Следующее
От: RekGRpth
Дата:
Сообщение: Re: BUG #17035: assert after commit