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

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

wieck(at)debis(dot)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