Marko Tiikkaja <> writes:
> On 1/14/14, 6:15 PM, Tom Lane wrote:
>> I'm not too sure what it'd take to make this work.  Right now,
>> SELECT (SELECT x, y FROM foo WHERE id = 42);
>> would generate "ERROR:  subquery must return only one column", but
>> I think it's mostly a historical artifact that it does that rather than
>> returning a composite value (of an anonymous record type).  If we were
>> willing to make that change then it seems like it'd be pretty
>> straightforward to teach plpgsql to handle
>> (a, b, ...) = row-valued-expression
>> where there wouldn't actually be any need to parse the RHS any differently
>> from the way plpgsql parses an assignment RHS right now.  Which would be
>> a good thing IMO.  If we don't generalize the behavior of scalar
>> subqueries then plpgsql would have to jump through a lot of hoops to
>> support the subselect case.

> You can already do the equivalent of  (a,b,c) = (1,2,3)  with SELECT .. 
> INTO.  Would you oppose to starting the work on this by only supporting 
> the subquery syntax, with the implementation being similar to how we 
> currently handle SELECT .. INTO?

You can try if you want, but I suspect it will result in writing a lot of
basically throwaway code, ie, not something that would be a precursor
of code that could support the generic-row-valued-expression case.

                        regards, tom lane

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to