From: 德哥 <digoal@126.com>
To: David G. Johnston <david.g.johnston@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
Subject: Re:Re: BUG #17036: generated column cann't modifyed auto when update
Date: Thu, 27 May 2021 17:21:34 +0800 (CST)
Message-ID: <d89a6f8.4d3a.179ad210afa.Coremail.digoal@126.com> (raw)
In-Reply-To: <CAKFQuwbDwpPyf=q-LPUfhiLYHhM_2X_86vXL=tQ0vESivtcN7g@mail.gmail.com>
References: <17036-e4d41f4221873a17@postgresql.org>
<CAKFQuwarr8b2=2j2J4GuSV-FwqAXq38ebFR_wTUY=Lg9_YLCJg@mail.gmail.com>
<23824c32.12e8.179ab97fa8a.Coremail.digoal@126.com>
<CAKFQuwbkoz3zmL_bEC2ndSX5G9_3xm_+AL2fd+3OTFFH0VePow@mail.gmail.com>
<2e46e6b5.1930.179abb8b6c0.Coremail.digoal@126.com>
<CAKFQuwbDwpPyf=q-LPUfhiLYHhM_2X_86vXL=tQ0vESivtcN7g@mail.gmail.com>
HI,
Using trigger is a good suggestion, we'll use trigger next, but I want to talk about whether this phenomenon is abnormal.
If the value of the immutable function changes, the immutable function should be recalculated.
For example, I have already demonstrated this:
` ` `
postgres=# create or replace function im_now (float8 default random()) returns timestamptz as $$
postgres$# select now();
postgres$# $$ language sql strict immutable;
CREATE FUNCTION
postgres=#
postgres=# create table t1 (id int primary key, c1 int, info text, crt_time timestamp,
postgres(# mod_time timestamp GENERATED ALWAYS AS (im_now()) stored);
CREATE TABLE
` ` `
2. How to explain this phenomenon? It doesn't seem to have been re-implemented! OK, I believe this is a bug. In addition to limiting the generated column expression to be immutable itself, we should also restrict the default value of the parameter to the function to be immutable.
best regards,
digoal
--
公益是一辈子的事,I'm Digoal,Just Do It.
在 2021-05-27 11:16:10，"David G. Johnston" <david.g.johnston@gmail.com> 写道：
On Wednesday, May 26, 2021, 德哥 <digoal@126.com> wrote:
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.
It was never a feature in the first place so nothing has been killed. The documentation says the function must be immutable. Your function is not. You should have used a trigger, and the fact you had to write a wrapper function to hack the volatility means that, frankly, its your disregard for a known limitation that has produced this need to change your application with the release of a new major version - not any bug or decision on the part of PostgreSQL.
David J.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: digoal@126.com, david.g.johnston@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re:Re: BUG #17036: generated column cann't modifyed auto when update
In-Reply-To: <d89a6f8.4d3a.179ad210afa.Coremail.digoal@126.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox