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

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-25 09:27:39
Message-ID: CAApHDvquT6uG-84nui=ixax-HdW0qfZ5vwa71kD6KTXDOpXK1A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 25 Jun 2020 at 16:56, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
> 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.

This is not a vote in either direction but just wanted to say that
during 7e413a0f8 where multi-row inserts were added to pg_dump, a
special case had to be added to support tables with no columns. We
cannot do multi-inserts for that so are forced to fall back on
one-row-per-INSERT.

However, even if we had this syntax I imagine it would be unlikely
we'd change pg_dump to use it since we want to be as standard
compliant as possible when dumping INSERTs since it appears the only
genuine use-case for that is for importing the data into some other
relational database.

David

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2020-06-25 09:43:00 Re: Online checksums patch - once again
Previous Message David Rowley 2020-06-25 09:15:21 Open Item: Should non-text EXPLAIN always show properties?