Marko Tiikkaja <ma...@joh.to> 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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
