Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> Ruling out this case would break a technique that I've used a lot in the
>> past, which is to put defaultable columns (eg, SERIAL columns) at the
>> end, so that they can simply be left out of quick manual inserts.
> Yes, I understand the tempation to put the columns needing default at
> the end and skipping them on INSERT. However, our new DEFAULT insert
> value seems to handle that nicely, certainly better than the old code
> did, and I think the added robustness of now requiring full columns on
> INSERT is worth it.
If I have two or three defaultable columns (say, a SERIAL primary key
and an insertion timestamp), it's going to be a pain in the neck to
have to write DEFAULT, DEFAULT, ... at the end of every insert.
I feel that people who want error cross-checking on this will have used
an explicit column list anyway. Therefore, Rod's patch tightens the
case that should be tight, while still being appropriately loose for
casual manual inserts.
BTW, I do *not* agree with equating this case with COPY. COPY is mostly
used for loading dumped data, and so it's reasonable to make different
tradeoffs between error checking and friendliness for COPY and INSERT.
regards, tom lane
