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

Philip Warner <pjw@rhyme.com.au> writes:
> At 12:07 10/11/00 -0500, Tom Lane wrote:
>> Something's got to be done about this --- not being able to load
>> 7.0 dump files will not do.

> I assume modifying pg_dump for 7.0.x is not an option,

Not really ...

> would
> there be any value in modifying the CREATE LANGUAGE code to output a
> warning for non-newC handlers? Or just updating the function definition
> (with a WARNING) when the language is created?

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.

>> At one time I had toyed with the idea of using 'C' to specify
>> dynamically-loaded functions that use the new-style fmgr API, and
>> 'oldC' for old-style fmgr API.  That would be nicer in the long run,
>> and it'd fix this particular problem, but it'd break dumped definitions
>> for user-defined C functions that haven't yet been updated to new-style
>> API.  That doesn't seem like an acceptable tradeoff.

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

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.
        regards, tom lane