Re: INSERT .. SET syntax

From: Vik Fearing <vik(at)2ndquadrant(dot)fr>
To: Marko Tiikkaja <marko(at)joh(dot)to>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: INSERT .. SET syntax
Date: 2016-09-03 17:50:30
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 08/31/2016 04:12 PM, Marko Tiikkaja wrote:
> Hello hello,
> Here's a rebased and updated patch for $SUBJECT for the September commit
> fest.


This patch is pretty straightforward, using mostly already existing
infrastructure. I tried to break it in various ways and could not. I
do have a few comments, though.

In insert.sgml, some things are <replaceable class="parameter"> and some
are <replaceable class="PARAMETER">. I don't expect this patch to fix
those inconsistencies, but it should certainly not perpetuate them.

This code comment in gram.y took me a while to figure out:

+ * This is different from set_clause_list used in UPDATE because the
+ * syntax already does everything you might want to do in an in INSERT.
+ */

If the SelectStmt is all we need, why is this patch here? I would
prefer wording such as "This is different from set_clause_list used in
UPDATE because we don't want multiple_set_clause. The INSERT INTO ...
SELECT variant may be more appropriate in such cases." Or something.

Aside from those trivialities, the main question about this patch is if
we actually want it. It is not standard SQL syntax, and the only other
product I've located that uses it (or anything like it) is MySQL.
However, I can see how it would be a huge win for very wide tables and
so my personal opinion is to accept this syntax as a PostgreSQL
extension to the standard.

Marking ready for committer, the minor gripes above notwithstanding.
Vik Fearing +33 6 46 75 15 36 PostgreSQL : Expertise, Formation et Support

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-09-03 17:59:32 Re: [sqlsmith] Failed assertion in numeric aggregate
Previous Message Simon Riggs 2016-09-03 16:57:08 Re: LSN as a recovery target