Re: Coping with 'C' vs 'newC' function language names - Mailing list pgsql-hackers
From | Philip Warner |
---|---|
Subject | Re: Coping with 'C' vs 'newC' function language names |
Date | |
Msg-id | 3.0.5.32.20001112121400.02bcf100@mail.rhyme.com.au Whole thread Raw |
In response to | Re: Coping with 'C' vs 'newC' function language names (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Coping with 'C' vs 'newC' function language names
(Tom Lane <tgl@sss.pgh.pa.us>)
|
List | pgsql-hackers |
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 |/
pgsql-hackers by date: