>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
Tom> Well, we've never considered implementation convenience to be moreTom> important than getting it right, and this
doesn'tseem like aTom> place to start.
I quote your own words from less than a year ago:
The standard actually says that the source for a multi-column assignment could be any row-valued expression. The
implementationused here is tightly tied to our existing sub-SELECT support and can't handle other cases; the Bison
grammarwould have some issues with them too. However, I don't feel too bad about this since other cases can be
convertedinto sub-SELECTs. For instance, "SET (a,b,c) = row_valued_function(x)" could be written "SET (a,b,c) =
(SELECT* FROM row_valued_function(x))".
(from the commit message for 8f889b108)
Tom> (FWIW, the raw-parser changes would be a negligible fraction ofTom> the work involved to do it like that.)
/** Ideally, we'd accept any row-valued a_expr as RHS of a multiple_set_clause.* However, per SQL spec the
row-constructorcase must allow DEFAULT as a row* member, and it's pretty unclear how to do that (unless perhaps we
allow*DEFAULT in any a_expr and let parse analysis sort it out later?). For the* moment, the planner/executor only
supporta subquery as a multiassignment* source anyhow, so we need only accept ctext_row and subqueries here.*/
(The "punt to parse analysis" solution looks reasonable to me, but I'm
just as in the dark as you were when you wrote that as to any other
possible solution.)
--
Andrew (irc:RhodiumToad)
