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

> System table updates
> --------------------
>
> In the initial phase, pg_language type 11 ("builtin") will be renamed
> to "old_builtin", and a new language type named "builtin" will be
> created with a new OID.  Then pg_proc entries will be changed from
> language code 11 to the new code piecemeal, as the associated routines
> are rewritten.  (This will imply several rounds of forced initdbs as
> the contents of pg_proc change.  It would be a good idea to add a
> "catalog contents version number" to the database version info checked
> at startup before we begin this process.)
>
> The existing pg_language entry for "C" functions will continue to
> describe user functions coded in the old style, and we will need to add
> a new language name for user functions coded in the new style.  (Any
> suggestions for what the new name should be?)  We should deprecate
> old-style functions because of their portability problems, but the
> support for them will only be one small function handler routine,
> so we can leave them in place for as long as necessary.
>
> The expected calling convention for PL call handlers will need to change
> all-at-once, but fortunately there are not very many of them to fix.

    This  approach  nearly  matches  all  my  thoughts  about the
    redesign of the fmgr. In the  system  table  section  I  miss
    named arguments.

    I think we need a new system table

    pg_proargs (
      Oid         pargprooid,
      int2        pargno,
      name        pargname,
      bool        pargdflnull,
      text        pargdefault
    );

    plus  another  flag  in  pg_proc  that tells if this function
    prototype information is available.

    The parser then has to handle function calls like

      ... myfunc(userid = 123, username = 'hugo');

    and build a complete function argument list that has all  the
    arguments  in  the  correct  order  and  defaults for omitted
    arguments filled  in  as  const  nodes.  This  new  prototype
    information  than  must  also  be  used in the PL handlers to
    choose the given names for arguments.

    In addition, we could add  an  argument  type  at  this  time
    (INPUT, OUTPUT and INOUT) but only support INPUT ones for now
    from the SQL level.  PL  functions  calling  other  functions
    could eventually use these argument types in the future.

    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.  As said in another
    mail, I think it must be done via some temp table since  most
    interpreter  languages  will  not  be  able  to do RETURN AND
    RESUME in any other way - not even PL/pgSQL will be easy  and
    would   need  a  total  internal  redesign  of  the  bytecode
    interpreter since it otherwise needs to recover the  internal
    call stack maybe across recursive calls.


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