Re:Re: BUG #17036: generated column cann't modifyed auto when update - Mailing list pgsql-bugs

From 德哥
Subject Re:Re: BUG #17036: generated column cann't modifyed auto when update
Date
Msg-id 2e46e6b5.1930.179abb8b6c0.Coremail.digoal@126.com
Whole thread Raw
In response to Re: BUG #17036: generated column cann't modifyed auto when update  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses 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>)
List 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 by date:

Previous
From: 德哥
Date:
Subject: Re:Re: BUG #17036: generated column cann't modifyed auto when update
Next
From: RekGRpth
Date:
Subject: Re: BUG #17035: assert after commit