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

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Mon, Oct 12, 2020 at 4:04 AM Jean Prulière <jean(at)oclock(dot)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