Re: [HACKERS] Function-manager redesign: second draft (long)

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

In response to

Responses

Browse pgsql-hackers by date

  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