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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | John Hansen | 2005-02-03 04:26:51 | Re: subselects in the target list |
Previous Message | Neil Conway | 2005-02-03 04:02:14 | subselects in the target list |