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 1mGTWI-0008UI-8l for pgsql-bugs@arkaria.postgresql.org; Wed, 18 Aug 2021 21:54:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mGTWF-0006O0-Nb for pgsql-bugs@arkaria.postgresql.org; Wed, 18 Aug 2021 21:54:43 +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 1mGTWE-0006Ns-U3 for pgsql-bugs@lists.postgresql.org; Wed, 18 Aug 2021 21:54:42 +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 1mGTWC-0003Qp-AP for pgsql-bugs@lists.postgresql.org; Wed, 18 Aug 2021 21:54:41 +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 17ILsald1621288; Wed, 18 Aug 2021 17:54:37 -0400 From: Tom Lane To: "David G. Johnston" cc: Peter Eisentraut , Petr Hybler , "pgsql-bugs@lists.postgresql.org" Subject: Re: PGSQL bug - "Column ??? is an identity column defined as GENERATED ALWAYS.", In-reply-to: References: <949dd35d-596e-efce-c5fb-bfef19b74d3b@enterprisedb.com> Comments: In-reply-to "David G. Johnston" message dated "Wed, 18 Aug 2021 14:15:37 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <1621286.1629323676.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Aug 2021 17:54:36 -0400 Message-ID: <1621287.1629323676@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "David G. Johnston" writes: > On Wednesday, August 18, 2021, Peter Eisentraut enterprisedb.com> wrote: >> This has been fixed in PostgreSQL 14. > The OP is reporting a regression, saying it is fixed in v14 isn=E2=80=99= t a useful > response. Is it also fixed in v11.14? The OP would have to provide some evidence that there's actually any regression. AFAIK that code was like that since IDENTITY columns were introduced. v14 does improve matters, but we judged the fix too invasive to risk back-patching. BTW, the v11 error message points out a simple workaround, which seems to do the trick: regression=3D# CREATE TABLE sample_table ( id int8 NOT NULL GENERATED ALWAYS AS IDENTITY, name varchar(255) NOT NULL, description text NOT NULL, CONSTRAINT sample_table_pk PRIMARY KEY (id) ); CREATE TABLE regression=3D# INSERT INTO sample_table (id, name, description)VALUES (DEF= AULT, 'John Doe', 'Test description') , (DEFAULT, 'Jane Eod', 'Not working'); ERROR: cannot insert into column "id" DETAIL: Column "id" is an identity column defined as GENERATED ALWAYS. HINT: Use OVERRIDING SYSTEM VALUE to override. regression=3D# INSERT INTO sample_table (id, name, description) OVERRIDING= SYSTEM VALUE VALUES (DEFAULT, 'John Doe', 'Test description') , (DEFAULT, 'Jane Eod', 'Not working'); INSERT 0 2 regression=3D# table sample_table; id | name | description = ----+----------+------------------ 1 | John +| Test description | Doe | = 2 | Jane Eod | Not working (2 rows) Yeah, per spec you shouldn't have to say OVERRIDING SYSTEM VALUE for this case, but it didn't seem worth the risk of back-patching to improve that in stable branches. regards, tom lane