Neil Conway <neilc@samurai.com> writes:
> On Wed, 2005-02-02 at 23:22 -0500, Tom Lane wrote:
>> The syntax you are showing is designed
>> to return a scalar. It will (and should) barf on multiple rows as well
>> as multiple columns.
> I don't understand; the example I posted is of an SRF that returns
> multiple rows of multiple columns, which is transformed into multiple
> rows of a single column of composite type.
I was speaking of the subselect syntax.
>> I'm unconvinced that it's worth fixing
>> considering that this whole behavior (SRFs in the targetlist) is
>> deprecated.
> It is? I think if we polished it somewhat, this is reasonably cool
> functionality to have, and is consistent with the 8.0 work to make
> composite types more widely usable.
What's deprecated is SETOF functions (ie, multiple return *rows*)
in the targetlist. Although that may appear to work, it doesn't
actually work very well --- in particular the behavior when you have
more than one in the same targetlist isn't real sensible. So I'm
not eager to see the subselect syntax extended to allow multiple
rows to be returned, which is the other thing that this line of
argument would lead to.
I don't particularly care one way or the other about allowing a
subselect to return a single row value; I'm just saying that reasoning
from the behavior of SRFs isn't necessarily a good guide to what to do.
There's some legacy behavior there.
regards, tom lane
