Re: BUG #15237: I got "ERROR: source for a multiple-column UPDATE item must be a sub-SELECT or ROW() expression"

Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Tom> It's telling you what to do: use a ROW() expression, ie
> Tom> update fvt_obj_operate_update_table_033 set (c_int) = row(20)
> Tom> where c_int = 20;

> Yeah, but (a) this used to work, and has worked since at least as far
> back as 9.0, and (b) the spec requires it to work.

As far as (a) goes, it was an intentional compatibility breakage,
cf commits 86182b189 and 906bfcad7, and as for (b), the SQL committee
is just nuts here. They've overloaded the syntax to the point where
it's unresolvable if you try to allow everything the spec suggests
should be allowed. The expectation in 906bfcad7 was that we'd move
towards the *other* thing the spec demands, namely that the RHS can
be any a_expr yielding a suitable row value. We can't do that if
it's unclear what is or isn't a ROW() expression, because then the
intended semantics would be undecidable. And I don't think we want
a situation in which adding "extra" parens changes a legal command
into an illegal one. For example, suppose f(...) returns a single-column
tuple result. This should be legal, if x matches the type of the single
column:

update ... set (x) = f(...)

but if we try to do what you seem to have in mind, this would not be:

update ... set (x) = (f(...))

That's sufficiently brain-dead that I don't think we want to go there.

regards, tom lane