Re: BUG #14952: COPY fails to fill in IDENTITY column default value
От | Michael Paquier |
---|---|
Тема | Re: BUG #14952: COPY fails to fill in IDENTITY column default value |
Дата | |
Msg-id | CAB7nPqSV3nHjgVb-f3arf52W+dvng2MmbTf3V+=0Sm-chR4Xxg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #14952: COPY fails to fill in IDENTITY column default value (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: