Re: [HACKERS] Function-manager redesign: second draft (long) - Mailing list pgsql-hackers

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@debis.com (Jan Wieck) #