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