From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Jan Wieck <wieck(at)debis(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, maillist(at)candle(dot)pha(dot)pa(dot)us, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Function-manager redesign: second draft (long) |
Date: | 1999-10-30 21:32:26 |
Message-ID: | 381B63EA.DC8F1F4@tm.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 1999-10-30 21:39:54 | Re: [HACKERS] Function-manager redesign: second draft (long) |
Previous Message | Vince Vielhaber | 1999-10-30 20:58:53 | Re: [HACKERS] missing mugshots |