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

>
> [ responding to both of Jan's messages in one ]
>
> wieck@debis.com (Jan Wieck) writes:
> >     I like the current interface for it's simpleness from the  user
> >     function   developers  point  of  view.
>
> There is that; even with a good set of convenience macros there will be
> more to learn about writing user functions.  OTOH, the way it is now
> is not exactly transparent --- in particular, NULL handling is so easy
> to forget about/get wrong.  We can make that much easier.  We can also
> simplify the interface noticeably for standard types like float4/float8.
>
> BTW: I am not in nearly as big a hurry as Bruce is to rip out support
> for the current user-function interface.  I want to get rid of old-style
> builtin functions before 7.0 because of the portability issue (see
> below).  But if a particular user is using old-style user functions
> and isn't having portability problems on his machine, there's no need
> to force him to convert, it seems to me.

    Personally,  I  could  live  with  dropping  the  entire  old
    interface. That's not the problem. But at least Bruce and his
    book  need  to  know  the final programming conventions if we
    ought to change it at all,  so  it  can  be  covered  in  his
    manuscript when it is sent down to the paper.

> I was going to let the prolang column tell that, by having different
> language codes for old vs. new builtin function and old vs. new
> dynamic-linked C function.  We could add a version column instead,
> but that seems like unnecessary complication.

    Right - language is all needed to tell.

> >     This  approach  nearly  matches  all  my  thoughts  about the
> >     redesign of the fmgr. In the  system  table  section  I  miss
> >     named arguments.
>
> As you said in your earlier message, that is a parser-level feature
> that has nothing to do with what happens at the fmgr level.  I don't
> want to worry about it for this revision.

    Right too. I just hoped to expand the scope of this change so
    there would only ONE change to the PL handlers covering both,
    new interface with proper NULL handling and enhanced function
    prototypes.

>
> >     Also  I miss the interface for tuple set returns. I know that
> >     this requires much more in other sections than only the fmgr,
> >     but  we  need  to  cover it now or we'll not be able to do it
> >     without another change to the fmgr interface at the  time  we
> >     want  to  support real stored procedures.
>
> OK, I'm willing to worry about that.  But what, exactly, needs to
> be provided in the fmgr interface?

    First we need another relation type in pg_class. It's like  a
    table  or  view, but none of the NORMAL SQL statements can be
    used with it (e.g.  INSERT, SELECT, ...). It just describes a
    row structure.

    Then,  a function returning a SET of any row type (this time,
    regular relations or views too) can be used in the rangetable
    as

        SELECT A.col1, B.col2 FROM mysetfunc() A, anothertab B
            WHERE A.col1 = B.col1;

    Of  course,  it  requires  some  new fields in the rangetable
    entry.  Anyway, at the beginning  of  execution  for  such  a
    query,  the  executor  initializes  those RTE's by creating a
    temptable with the  schema  of  the  specified  structure  or
    relation.  Then  it  calls the user function, passing in some
    handle to the temp table and the user function fills  in  the
    tuples. Now the rest of query execution is if it is a regular
    table. After execution, the temp table is dropped.

    Isn't that all required for true stored procedures?


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