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

Hannu Krosing wrote:
>
> Jan Wieck wrote:
> >
> > 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;

Exactly that's something I want for long now. Sticking
another querytree, that returns a tuple set, into a
rangetable entry. This other querytree could be either a
SELECT as in

SELECT A.x, A.y, B.z FROM table1 A, (SELECT ...) B
WHERE A.x = B.x;

or a function returning a set as in

SELECT A.x, A.y, B.z FROM table1 A, setfunc('arg') B
WHERE A.x = B.x;

Finally, the form

CALL setfunc('arg');

would be equivalent to a

SELECT * FROM setfunc('arg');

but closer to the IBM DB2 calling syntax. The first one is
required to get rid of some problems in the rule system,
especially views with aggregate columns that need their own
GROUP BY clause. The other ones are what we need to implement
stored procedures.

>
> or at least define views on them:
>
> CREATE VIEV LOGGED_IN_USERS AS CALL FUNCTION LOGGED_IN_USERS_INFO_PROC;

Wrong syntax since the statement after AS must be a SELECT.
But a

CREATE VIEW v AS SELECT * FROM setfunc();

would do the trick.

>
> 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;

Let's clearly distinguish between scalar, row and set return
values. A scalar return value is one single datum. A row
return value is exactly one tuple of 1...n datums and a set
return value is a collection of 0...n rows.

What we have now (at least what works properly) are only
scalar return values from functions. And I don't see the
point of a row return, so I think we don't need them.

>
> 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 ;)

But please don't forget that it isn't enough to write down
the syntax and specify the behaviour with some english words.
We must define the behaviour in C too, and in that language
it's a little more than a redundant case of something,
because we don't have that something.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck(at)debis(dot)com (Jan Wieck) #