pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: 德哥 <digoal@126.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: 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:24:44 +0800 (CST)
Message-ID: <574cb2f7.4da8.179ad23f309.Coremail.digoal@126.com> (raw)
In-Reply-To: <1684301.1622084940@sss.pgh.pa.us>
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>
	<1684301.1622084940@sss.pgh.pa.us>




Thank you Tom Lane for your reply. I think your explanation is very clear.

So can we talk about the use of volatile or stable functions in generated columns and if there are actual business scenarios, why not design the functionality from the perspective of the scenarios instead of the scenarios?










--

公益是一辈子的事,I'm Digoal,Just Do It.






At 2021-05-27 11:09:00, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
>=?GBK?B?tcK45w==?= <digoal@126.com> writes:
>> 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.
>
>You have been told several times already that this is not a "feature".
>The point of the restriction that GENERATED expressions be immutable
>is that the implementation need not recompute them during UPDATE
>(if none of their input columns changed).
>
>If v12 failed to exploit that fully, that's more a bug in v12 than
>it is in versions that do exploit it.
>
>If you need to update a column during every update, the best way
>to do that is with a BEFORE INSERT OR UPDATE trigger.
>
>I will also state categorically that lying about the mutability
>of a function is a technique that will bite you on the rear, and
>you will get no sympathy when it does.  If it does what you want
>in version N, fine, but don't whine when it breaks in N+1.
>
>			regards, tom lane


view thread (15+ messages)  latest in thread

Message-ID: <574cb2f7.4da8.179ad23f309.Coremail.digoal@126.com>
Permalink:  ../574cb2f7.4da8.179ad23f309.Coremail.digoal@126.com/
Also on:    postgresql.org/message-id/574cb2f7.4da8.179ad23f309.Coremail.digoal@126.com

 · 

reply

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, tgl@sss.pgh.pa.us, 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: <574cb2f7.4da8.179ad23f309.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