Re: AW: Shouldn't this be an error? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: AW: Shouldn't this be an error?
Date
Msg-id 25152.980789445@sss.pgh.pa.us
Whole thread Raw
In response to AW: Shouldn't this be an error?  (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>)
Responses Re: AW: Shouldn't this be an error?  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: AW: Shouldn't this be an error?  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Zeugswetter Andreas SB  <ZeugswetterA@wien.spardat.at> writes:
>> A compromise position would be to allow dropping trailing columns only
>> when the column name list is omitted.

> Sounds reasonable to me.

IIRC, there's some interaction between this behavior and the way that
INSERT ... DEFAULT VALUES is implemented; I think DEFAULT VALUES is
parsed as an empty values list and then the trailing-column-omission
code is what actually makes the right things happen.  So changing it
without breaking DEFAULT VALUES is not entirely trivial; it'll take
some changes in the raw-parsetree representation.  There are other
missing SQL features hereabouts also, such as being able to write
a DEFAULTed column explicitly:INSERT ... VALUES('foo', DEFAULT, 42);
and being able to insert multiple explicit rows:INSERT ... VALUES('foo', DEFAULT, 42), VALUES('bar', 99, 44);
I think we should deal with all of these issues at once, which means
it's not something to try to fix for 7.1.  Bruce, would you add a
TODO item?
 * Bring INSERT ... VALUES up to full SQL92 spec.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: Open 7.1 items
Next
From: Bruce Momjian
Date:
Subject: Re: AW: Shouldn't this be an error?