Skip site navigation (1) Skip section navigation (2)

Re: subselects in the target list

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: subselects in the target list
Date: 2005-02-03 05:17:19
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Neil Conway <neilc(at)samurai(dot)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

In response to

pgsql-hackers by date

Next:From: Simon RiggsDate: 2005-02-03 06:10:41
Subject: LWLock cache line alignment
Previous:From: Greg Sabino MullaneDate: 2005-02-03 05:16:24
Subject: Re: [NOVICE] Last ID Problem

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group