To: Markus Schaber <schabi@logix-tt.com>
cc: PostGIS Users Discussion <postgis-users@postgis.refractions.net>,
	PostgreSQL SQL List <pgsql-sql@postgresql.org>
Subject: Re: Problem using set-returning functions 
In-reply-to: <4427C15C.5070905@logix-tt.com> 
References: <20060324200036.ED8E52C1503@netnation.refractions.net>
	<1143278826.44250cea7eccc@web-mail1.uibk.ac.at>
	<4427BFE4.8050500@logix-tt.com> <4427C15C.5070905@logix-tt.com>
Comments: In-reply-to Markus Schaber <schabi@logix-tt.com>
	message dated "Mon, 27 Mar 2006 12:41:32 +0200"
Date: Mon, 27 Mar 2006 10:48:30 -0500
Message-ID: <14736.1143474510@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Markus Schaber <schabi@logix-tt.com> writes:
> navteq=# select foo,generate_x(bar) from test;
> ERROR:  set-valued function called in context that cannot accept a set
> CONTEXT:  PL/pgSQL function "generate_x" line 5 at return next

plpgsql SRFs don't support being called from the SELECT target list,
only from a FROM-expression.  Your other function is probably written
in SQL not plpgsql; SQL functions do support this.

plpgsql could probably be fixed if we were really motivated to do so,
but I think most people who have looked at it feel we should phase out
the capability to call SRFs from a target list, rather than extend it.
It's weird and not very semantically sound --- in particular, there's no
very sensible definition if there's more than one of them in the target
list.  See past discussions in the PG archives.

			regards, tom lane