Re: Support UPDATE table SET(*)=...

>>>>> "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)