"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