Re: Why forbid "INSERT INTO t () VALUES ();"

From: ilmari(at)ilmari(dot)org (Dagfinn Ilmari Mannsåker )
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Thomas Kellerer <shammat(at)gmx(dot)net>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Why forbid "INSERT INTO t () VALUES ();"
Date: 2020-06-24 22:31:00
Message-ID: 875zbgnljv.fsf@wibble.ilmari.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> writes:
>>>> 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.
>
> We allow zero-column syntaxes in some other places where SQL forbids
> them, 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?

FWIW, MySQL (and MariaDB) only support INSERT INTO t () VALUES (), not
DEFAULT VALUES. We have added syntax for MySQL compatibility in the
past, e.g. the CONCAT() function.

- ilmari
--
"A disappointingly low fraction of the human race is,
at any given time, on fire." - Stig Sandbeck Mathisen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2020-06-24 23:03:40 Re: Why forbid "INSERT INTO t () VALUES ();"
Previous Message Daniel Gustafsson 2020-06-24 22:30:03 Re: should libpq also require TLSv1.2 by default?