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

Re: subselects in the target list

From: John Hansen <john(at)geeknet(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Neil Conway <neilc(at)samurai(dot)com>,pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: subselects in the target list
Date: 2005-02-03 04:26:51
Message-ID: 1107404811.26839.32.camel@localhost.localdomain (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, 2005-02-02 at 23:22 -0500, Tom Lane wrote:
> Neil Conway <neilc(at)samurai(dot)com> writes:
> > neilc=# select a, (select * from abc) from abc;
> > ERROR:  subquery must return only one column
> 
> > Is there a reason we can't treat a subselect in the target list as
> > returning a composite type?
> 
> Given the 8.0 infrastructure for unnamed record types it might be
> possible to do that; it was surely never possible before.  Whether it's
> a good idea is another question.  The syntax you are showing is designed
> to return a scalar.  It will (and should) barf on multiple rows as well
> as multiple columns.

Right, the point is, that is does not, if said srf-function is written
in say, C.

However, this is somewhat similar to the WITH LATERAL clause previously
discussed in connection with UNNEST and multisets, so perhaps it's not
such a bad idea after all?

> > For that matter, is this behavior also intentional?
> 
> > neilc=# select a, foo_abc2() FROM abc;
> > ERROR:  set-valued function called in context that cannot accept a set
> > CONTEXT:  PL/pgSQL function "foo_abc2" line 1 at return next
> 
> It's an implementation restriction in plpgsql: we didn't make it support
> the old-style SRF API.  I'm unconvinced that it's worth fixing
> considering that this whole behavior (SRFs in the targetlist) is
> deprecated.
> 
> 			regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
-- 
John Hansen <john(at)geeknet(dot)com(dot)au>
GeekNET


In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-02-03 04:49:42
Subject: Re: pg_dump bug in 7.3.9 with sequences
Previous:From: Tom LaneDate: 2005-02-03 04:22:24
Subject: Re: subselects in the target list

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