INSERT .. SET syntax

On Mon, Jul 4, 2016 at 1:06 AM, Marko Tiikkaja <marko@joh.to> wrote:

Hi,

Here's a patch for $SUBJECT. I'll probably work on the docs a bit more
before the next CF, but I thought I'd post it anyway.

I could see that it can be useful in certain cases as described in the
documentation part of the patch. I noticed that you have used
transformUpdateTargetList() to generate expression list for this case,
but that function raises some internal errors which indicates that
error is from Update. I think that might be misleading to users, if
they ever got raised.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Hello hello,

Here's a rebased and updated patch for $SUBJECT for the September commit
fest.

.m

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.

Review:

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
SelectStmt
+ * 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
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 3 July 2016 at 20:36, Marko Tiikkaja <marko@joh.to> wrote:

Here's a patch for $SUBJECT. I'll probably work on the docs a bit more
before the next CF, but I thought I'd post it anyway.

I think this should be Returned With Feedback.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 09/05/2016 03:58 PM, Simon Riggs wrote:

On 3 July 2016 at 20:36, Marko Tiikkaja <marko@joh.to> wrote:

Here's a patch for $SUBJECT. I'll probably work on the docs a bit more
before the next CF, but I thought I'd post it anyway.

I think this should be Returned With Feedback.

You're probably right (even though you're quoting the wrong message), so
I've changed it to that.

Marko, please resubmit an updated patch.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers