Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lmId7-0002yw-AZ for pgsql-bugs@arkaria.postgresql.org; Thu, 27 May 2021 16:13:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lmId5-0001ep-RL for pgsql-bugs@arkaria.postgresql.org; Thu, 27 May 2021 16:13:03 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lmId5-0001eh-Km for pgsql-bugs@lists.postgresql.org; Thu, 27 May 2021 16:13:03 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lmIcz-0003eL-Gy for pgsql-bugs@lists.postgresql.org; Thu, 27 May 2021 16:13:02 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 14RGCb6K1784317; Thu, 27 May 2021 12:12:37 -0400 From: Tom Lane To: "David G. Johnston" cc: =?UTF-8?B?5b635ZOl?= , "pgsql-bugs@lists.postgresql.org" Subject: Re: BUG #17036: generated column cann't modifyed auto when update In-reply-to: References: <17036-e4d41f4221873a17@postgresql.org> <23824c32.12e8.179ab97fa8a.Coremail.digoal@126.com> <2e46e6b5.1930.179abb8b6c0.Coremail.digoal@126.com> <1709810.1622123157@sss.pgh.pa.us> Comments: In-reply-to "David G. Johnston" message dated "Thu, 27 May 2021 08:11:48 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1784315.1622131957.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Thu, 27 May 2021 12:12:37 -0400 Message-ID: <1784316.1622131957@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "David G. Johnston" writes: > I am curious whether the SQL standard is imposing this immutable-only > limitation or whether we choose to do it ourselves. Fair question. What I read in SQL:2021 11.4 SR 10 is 10) If GC is specified, then: a) Let GE be the contained in GC. b) C is a generated column. c) Every contained in GE shall reference a base column = of T. d) GE shall not contain a possible source of non-determinism. e) GE shall not contain a whose subject routine possi= bly reads SQL-data. f) GE shall not contain a . Now, (d) is referring to 9.16 "Potential sources of non-determinism", which calls out a whole bunch of stuff that we would refer to as either volatile or stable; for example 9.16 1) k) says that all s (that is, CURRENT_TIMESTAMP etc) are potentially nondeterministic. So although the spec's two classes of function stability ::=3D DETERMINISTIC | NOT DETERMINISTIC don't map exactly to our IMMUTABLE/STABLE/VOLATILE classification, it seems correct to me to identify DETERMINISTIC with IMMUTABLE. It's certainly indisputable that the letter of the spec forbids CURRENT_TIMESTAMP in GENERATED expressions, and there's nothing suggesting that hiding that within a user-defined function makes it okay. regards, tom lane