Jan Wieck wrote:
>
...
>
> 5. Functions returning a set of result rows taking only
> input-arguments.
...
> So the only thing that's really left is number 5. The funny
> detail is, that those functions or procedures can't be used
> inside regular SELECT queries. Instead a CALL FUNCTION or
> EXECUTE PROCEDURE statement is used from the client
> application or inside a PL block. CALL FUNCTION then returns
> a tuple set as a SELECT does. The result in our world
> therefore has a tuple descriptor and depending on the invoker
> is sent to the client or stored in an SPI tuple table.
>
> So we do not need to call functions returning sets through
> the normal function manager. It could competely deny calls to
> set functions, and the interface for them can be a total
> different one. I have something in mind that could work
> without temp tables, but it requires a redesign for PL/pgSQL
> and causes some limitations for PL/Tcl. Let's leave that for
> a past 7.0 release.
>
> I correct my previous statements and vote to deny calls to
> set functions through the default function manager in 7.0.
>
It would be very nice if we could use the tuple-set-returning
functions in place of tables/views,
SELECT * FROM LOGGED_IN_USERS_INFO_PROC;
or at least define views on them:
CREATE VIEV LOGGED_IN_USERS AS CALL FUNCTION LOGGED_IN_USERS_INFO_PROC;
We would not need to call them in place of functions that return
either single-value or tuple.
On the topic of 2x3=6 kinds of functions you mentioned I think we
could use jet another type of functions - the one returning a
tuple/row as is ofteh case in python and possibly other languages
that do automatic tuple packing/unpacking.
It could be used in cases like this:
INSERT INTO MY_TABLE CALL FUNCTION MY_ROW_VALUE;
or
DELETE FROM MY_TABLE WHERE * = CALL FUNCTION MY_ROW_VALUE;
(The last example is not ansi and does not work currently),
OTOH, these exaples would jus be redundant cases for your 5th case.
OTOOH, all the functions returning less than a set of rows are
redundadnt cases of the functions that do ;)
-----------
Hannu
