Re: [PATCH] Implement INSERT SET syntax

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Steele <david(at)pgmasters(dot)net>
Cc: Gareth Palmer <gareth(at)internetnz(dot)net(dot)nz>, Michael Paquier <michael(at)paquier(dot)xyz>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Implement INSERT SET syntax
Date: 2020-03-24 18:45:55
Message-ID: 24422.1585075555@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> No doubt that's all fixable, but the realization that some cases of
> this syntax are *not* just syntactic sugar for standards-compliant
> syntax is giving me pause. Do we really want to get out front of
> the SQL committee on extending INSERT in an incompatible way?

One compromise that might be worth thinking about is to disallow
multiassignments in this syntax, so as to (1) avoid the possibility
of generating something that can't be represented by standard INSERT
and (2) get something done in time for v13. The end of March is not
that far off. Perhaps somebody would come back and extend it later,
or perhaps not.

A slightly more ambitious compromise would be to allow multiassignment
only when the source can be pulled apart into independent subexpressions,
comparable to the restriction we used to have in UPDATE itself (before
8f889b108 or thereabouts).

In either case the transformation could be done right in gram.y and
a helpful error thrown for unsupported cases.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2020-03-24 18:46:39 Re: Add A Glossary
Previous Message Jeremy Finzel 2020-03-24 18:32:49 How to only auto-restart BGW only on crash or _PG_init