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