Re: Identity column behavior discrepancies when inserting one or many rows

"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Mon, Oct 12, 2020 at 4:04 AM Jean Prulière <jean@oclock.io> wrote:
>> Here is a very simple script to reproduce what we encountered :
>> 
>> CREATE TABLE test (
>> id int GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
>> sometext text NOT NULL
>> );
>> 
>> -- that one works : INSERT 0 1
>> -- I think it should not and throw a 428C9
>> INSERT INTO test (id, sometext)
>> 
>> VALUES (DEFAULT, 'test');
>> 
>> -- this one does not : SQL state : 428C9
>> INSERT INTO test (id, sometext)
>> 
>> VALUES (DEFAULT, 'test2'),
>> (DEFAULT, 'test3');

> I agree the inconsistency seems to be undocumented but I wonder why the
> second case doesn't work, not why the first one does.  INSERT says: "For a
> generated column, specifying this is permitted but merely specifies the
> normal behavior of computing the column from its generation expression."
> That says the first case works, default means the same as omitting the
> column altogether.

Yeah.  Ideally both examples should work.  The fact that the second one
does not is an implementation deficiency: the code that recognizes no-op
DEFAULTs for this purpose doesn't descend into multi-row VALUES lists.
Somebody submitted a patch to improve that awhile ago, but I didn't like
the first version and there hasn't been an update yet:

https://commitfest.postgresql.org/30/2681/

Perhaps you could get your students interested in rewriting that patch?

            regards, tom lane