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
