Hello Tom,
>>>> INSERT INTO t() VALUES ();
>
>> I'm still unclear why it would be forbidden though, it seems logical to
>> try that, whereas the working one is quite away from the usual syntax.
>
> It's forbidden because the SQL standard forbids it.
Ok, that is definitely a reason. I'm not sure it is a good reason, though.
Why would the standard forbid it? From the language design point of view,
it is basically having a syntax for lists which would not work for empty
lists, or a syntax for strings which would not work for empty strings.
It also means that if for some reason someone wants to insert several such
all-default rows, they have to repeat the insert, as "VALUES (), ();"
would not work, so it is also losing a corner-corner case capability
without obvious reason.
> We allow zero-column syntaxes in some other places where SQL forbids
> them,
Then forbidding there it just adds awkwardness: the same thing works in
one place but not in another. That does not help users.
> but that's only because there is no reasonable alternative. In this
> case, there's a perfectly good, standards-compliant alternative. So why
> encourage people to write unportable code?
I doubt that people look at the (costly) standard when writing corner case
queries, they just try something logical as I did.
As some other databases accepts it, and if it is already allowed elsewhere
in pg, encouraging portability is not the main issue here. I'd rather have
logic and uniformity accross commands.
If I'm annoyed enough to send a patch some day, would you veto it because
it departs from the standard?
Anyway, thanks for the answer!
--
Fabien.
