Re: Coping with 'C' vs 'newC' function language names

At 10:55 11/11/00 -0500, Tom Lane wrote:
>
>Just outputting a warning is possible, but it still leaves you with a
>broken database after you reload your 7.0 dump file :-(. (And there
>isn't any supported way to fix it, short of reloading all your function
>definitions...) I thought about the fix-handler-at-CREATE-LANGUAGE-time
>option, but it doesn't seem noticeably cleaner than hacking CREATE
>FUNCTION.

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?

>> Another option in the long run would be to use language 'C' in all cases
>> and add an attribute which allows people to specify the function manager to
>> use. For 7.1 this would default to 'fmgr71' or some such.
>
>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. 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.

>More to the point, I think we have to assume old-style interface if we
>see ... LANGUAGE 'C' with no other decoration, because any other
>assumption is guaranteed to break all existing user-defined functions.

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.

What about (not for 7.1) adding the ability for the fmgr to query object
modules. eg. look for an entry point 'pg_fmgr_info' or similar, and if
found call it to get attrs of functions. Then the person defining the
function in the database is freed of the need for a large amount of
information about the functions. 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...

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/