Re: pg_dump multi VALUES INSERT - Mailing list pgsql-hackers

From David Rowley
Subject Re: pg_dump multi VALUES INSERT
Date
Msg-id CAKJS1f-D96ewCk6rL7oSDE45ooGT0AoqOKdVBn3Ej+ukdugwAg@mail.gmail.com
Whole thread Raw
In response to Re: pg_dump multi VALUES INSERT  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: pg_dump multi VALUES INSERT  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Wed, 23 Jan 2019 at 04:08, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> Is it possible to avoid the special case for 0 columns by using the
> UNION ALL syntax I showed?

It would be possible, but my thoughts are that we're moving away from
the SQL standard by doing so.

Looking at the standard I see:

<row value constructor element list> ::=
<row value constructor element> [ { <comma> <row value constructor
element> }... ]

so it appears that multirow VALUES clauses are allowed.

INSERT INTO ... DEFAULT VALUES; is standard too, but looking at
SELECT, neither the target list or FROM clause is optional.

You could maybe argue that 0-column tables are not standard anyway.
Going by DROP COLUMN I see "4) C shall be a column of T and C shall
not be the only column of T.". Are we the only database to break that?

I think since pg_dump --inserts is meant to be for importing data into
other databases then we should likely keep it as standard as possible.

Another argument against is that we've only supported empty SELECT
clauses since 9.4, so it may not help anyone who mysteriously wanted
to import data into an old version. Maybe that's a corner case, but
I'm sure 0 column tables are too.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: Typo: llvm*.cpp files identified as llvm*.c
Next
From: leif@lako.no
Date:
Subject: Fwd: Re: BUG #15589: Due to missing wal, restore ends prematurelyand opens database for read/write