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
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? |