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 04:22:24
Message-ID: 11492.1107404544@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

> 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

In response to

Responses

pgsql-hackers by date

Next:From: John HansenDate: 2005-02-03 04:26:51
Subject: Re: subselects in the target list
Previous:From: Neil ConwayDate: 2005-02-03 04:02:14
Subject: subselects in the target list

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