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

[ responding to both of Jan's messages in one ]

wieck@debis.com (Jan Wieck) writes:
>     I like the current interface for it's simpleness from the  user
>     function   developers  point  of  view.

There is that; even with a good set of convenience macros there will be
more to learn about writing user functions.  OTOH, the way it is now
is not exactly transparent --- in particular, NULL handling is so easy
to forget about/get wrong.  We can make that much easier.  We can also
simplify the interface noticeably for standard types like float4/float8.

BTW: I am not in nearly as big a hurry as Bruce is to rip out support
for the current user-function interface.  I want to get rid of old-style
builtin functions before 7.0 because of the portability issue (see
below).  But if a particular user is using old-style user functions
and isn't having portability problems on his machine, there's no need
to force him to convert, it seems to me.

>     And  converting  ALL
>     internal  plus  most  of  the  contrib  directories  ones  to
>     something new is really a huge project.

It is.  I was hoping to get some help ;-) ... but I will do it myself
if I have to.

>     ... And there are only  a  few  internal
>     functions  where  a new fmgr interface really is required due
>     to incomplete NULL handling or the like.

If your goal is *only* to deal with the NULL issue, or *only* to get
things working on a specific platform like Alpha, then yes we could
patch in a few dozen places and not undertake a complete changeover.
But I believe that we really need to fix this right, because it will
keep coming back to haunt us until we do.  I will not be happy as
long as we have ports that have to compile "-O0" because of fmgr
brain-damage.  I fear there are going to be more and more such ports
as people install smarter compilers that assume they are working with
ANSI-compliant source code.  We're giving up performance system-wide
because of fmgr.

>     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?

I was going to let the prolang column tell that, by having different
language codes for old vs. new builtin function and old vs. new
dynamic-linked C function.  We could add a version column instead,
but that seems like unnecessary complication.

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

I think it should be possible to make fmgr_faddr call both old and
new functions --- I haven't actually written code yet, but I think
I can do it.  You're right that that's important in order to spread
out the repair work instead of having a "big bang".

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

As you said in your earlier message, that is a parser-level feature
that has nothing to do with what happens at the fmgr level.  I don't
want to worry about it for this revision.

>     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.

OK, I'm willing to worry about that.  But what, exactly, needs to
be provided in the fmgr interface?
        regards, tom lane