Re: subselects in the target list
От | John Hansen |
---|---|
Тема | Re: subselects in the target list |
Дата | |
Msg-id | 1107404811.26839.32.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: subselects in the target list (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Wed, 2005-02-02 at 23:22 -0500, Tom Lane wrote: > Neil Conway <neilc@samurai.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@geeknet.com.au> GeekNET
В списке pgsql-hackers по дате отправления: