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

> 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(at)debis(dot)com (Jan Wieck) #