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

>
> > This is a followup to a message I wrote in June about reworking the fmgr
> > interface.  I've had a couple of good ideas (I think ;-)) since then,
> > but there are some parts of the proposal that still need work before
> > implementation can begin.
> >
> > I could particularly use some feedback from Jan and anyone else who's
> > worked with function-call handlers: does this design eliminate the
> > kluges that you've had to use in the past?  If not, what else is needed?
>
> Sounds good.  My only question is whether people need backward
> compatibility, and whether we can remove the compatiblity part of the
> interface and small overhead after 7.1 or later?

    Backward  compatibility is a common source of problems, and I
    don't like it generally. In the case of the fmgr it is  quite
    a  little  difficult,  and  I thought about it too already. I
    like the current interface for it's simpleness from the  user
    function   developers  point  of  view.  And  converting  ALL
    internal  plus  most  of  the  contrib  directories  ones  to
    something new is really a huge project.

    All   function  calls  through  the  fmgr  use  the  FmgrInfo
    structure, but there are alot of calls to internal  functions
    like  textout() etc. too. Changing their interface would IMHO
    introduce many problems. And there are only  a  few  internal
    functions  where  a new fmgr interface really is required due
    to incomplete NULL handling or the like.

    Therefore I would prefer an interface extension, that doesn't
    require  changes  to  existing functions. What about adding a
    proifversion  to  pg_proc,  telling  the  fmgr   which   call
    interface  the  function  uses?  This  is  then  held  in the
    FmgrInfo struct too so the fmgr can call a function using the
    old and new interface.

    First  fmgr_info()  is  extended to put the interface version
    into the  FmgrInfo  too.  Then  fmgr_faddr()  is  renamed  to
    fmgr_faddr_v1() and it has to check that only functions using
    the old interface are called through it  (there  aren't  that
    many  calls  to  it as you might think).  After that you have
    all the time in the world to implement another interface  and
    add  a  switch into fmgr() and sisters handling the different
    versions.

    My thoughts for the new interface:

    o   Each function argument must have it's separate NULL flag.

    o   The functions result must have another NULL flag too.

    o   Argument names and default values for omitted ones aren't
        IMHO something to  go  into  the  interface  itself.  The
        function is allways called with all arguments positional,
        the parser must provide this list.

    o   The new interface must at least be designed for  a  later
        implementation of tuple set returns. I think this must be
        implemented as a temp table, collecting all return tuples
        since for a procedural language it might be impossible to
        implement a real RETURN AND RESUME (like  it  is  already
        for  PL/Tcl  and  it  would  be  for  PL/Perl). Therefore
        another STRUCT  kind  of  relation  must  be  added  too,
        providing  the  tupdesc  for the returned set.  This temp
        table, filled by calling the function at the first time a
        tuple is needed and then it is simply another RTE.


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