From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thomas Kellerer <spam_eater(at)gmx(dot)net> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Identity columns, DEFAULT keyword and multi-row inserts |
Date: | 2019-12-11 15:24:37 |
Message-ID: | ac250211-6fa6-715e-5b32-072358571661@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 2019-12-10 17:53, Tom Lane wrote:
>> However, a multi-row insert like the following:
>> insert into test (id, data)
>> values
>> (default,1),
>> (default,2);
>> fails with:
>> ERROR: cannot insert into column "id"
>> Detail: Column "id" is an identity column defined as GENERATED ALWAYS.
>> Hint: Use OVERRIDING SYSTEM VALUE to override.
> Yeah, in principle a multi-row INSERT could grovel through all the
> rows of the VALUES clause and confirm that every one of them has
> DEFAULT there. Not sure it's worth the trouble, but if it's not
> a lot of code then maybe. It certainly seems a bit inconsistent.
It looks like the multi-row case in transformInsertStmt() would have to
develop a bit more smarts to discover this case and then replace the RTE
reference in the target list with a single SetToDefault node?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Zwettler Markus (OIZ) | 2019-12-11 15:25:57 | AW: AW: secure deletion of archived logs |
Previous Message | Олег Самойлов | 2019-12-11 13:25:36 | Re: tcp keep alive don't work when the backend is busy |