Re: BUG #14952: COPY fails to fill in IDENTITY column default value - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: BUG #14952: COPY fails to fill in IDENTITY column default value
Date
Msg-id CAB7nPqSV3nHjgVb-f3arf52W+dvng2MmbTf3V+=0Sm-chR4Xxg@mail.gmail.com
Whole thread Raw
In response to Re: BUG #14952: COPY fails to fill in IDENTITY column default value  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Thu, Dec 14, 2017 at 12:39 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> For that matter, should build_column_default() know about it explicitly
> either?  Why aren't we implementing IDENTITY by storing an appropriate
> default expression in the catalogs?

Wait a minute... If I look at the callers of build_column_default(),
rewriteValuesRTE looks broken as well:
=# CREATE TABLE itest10 (a int GENERATED BY DEFAULT AS IDENTITY, b
text, c bigint);
CREATE TABLE
=# insert into itest10 values (default, 'foo', 0), (default, 'foo2', 1);
ERROR:  23502: null value in column "a" violates not-null constraint
DETAIL:  Failing row contains (null, foo, 0).
I would expect the second query to work properly.

It seems that slot_fill_defaults() would fail as well for a logical
worker, and so are ATExecAlterColumnType() and ATExecAddColumn()?
Peter, did you do the separation to help in handling better the cases
with INSERT OVERRIDE?
-- 
Michael


pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #14952: COPY fails to fill in IDENTITY column default value
Next
From: Evgeniy Kozlov
Date:
Subject: Re: BUG #14972: row duplicate on first SELECT from CTE (by JOIN/FORUPDATE) from which UPDATE performed recently