Philip Warner <pjw@rhyme.com.au> writes:
> Is it the PL manager stuff that requires the new interface for all
> languages, or is it up to the PL implementor to choose the language for
> their handler?
The current fmgr implementation requires PL handlers to be newC or
newInternal. That could be relaxed, but I don't see any reason to do
so, since an old-style handler would be incapable of handling null
arguments/results or supporting triggers.
>> No, that just adds complexity without really accomplishing anything.
>>> From the function manager's point of view, the "language" setting *is*
>> the interface, they're not separately twiddlable concepts.
> It does avoid "language 'evenNewerC'" in the furture.
How so? It appears to me it would just move the 'evenNewerFoo'
dirtiness to a different keyword, which would still be essential
for the user to write. Net result: no gain, just more writing.
> By allowing optional
> attributes to use older fmgr interfaces we preserve compatibility without
> cluttering the list of languages. From the developer/user point of view,
> the language is 'C' if it's written in C.
No. 'C' is really a misnomer, since it does NOT imply anything about
whether the code is in C or not --- in theory you could use any language
that's link-compatible with C. What LANGUAGE 'C' really implies is
"dynamically linked, compiled function following fmgr interface
convention #1"", as opposed to (for example) LANGUAGE 'internal' which
implies "statically linked, compiled function following fmgr interface
convention #1". Nothing about language at all.
> Quite right. The (unspecified) plan was to allow an environmental setting
> that set the default attr for "language 'C'" functions. Then restoring a
> dump file would be a matter of setting this variable to use the old
> interface at the start of the script.
Interesting idea, but it'll fall down as soon as there's more than one
possible value. You don't think that people are going to update all
their functions to a new interface style at the same time, do you?
> Might even be able to implement a 'CREATE MODULE' which loads an
> object, enquires about functions in the module, and creates function
> entries based on information returned from pg_fmgr_info...
That could work ... something to think about for the future, anyway.
regards, tom lane
