Re: [HACKERS] Function-manager redesign: second draft (long) - Mailing list pgsql-hackers
From | wieck@debis.com (Jan Wieck) |
---|---|
Subject | Re: [HACKERS] Function-manager redesign: second draft (long) |
Date | |
Msg-id | m11g2Yt-0003kLC@orion.SAPserv.Hamburg.dsh.de Whole thread Raw |
In response to | Re: [HACKERS] Function-manager redesign: second draft (long) (Bruce Momjian <maillist@candle.pha.pa.us>) |
Responses |
Re: [HACKERS] Function-manager redesign: second draft (long)
|
List | pgsql-hackers |
> > > 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) #
pgsql-hackers by date: