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

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, since we really need
to support loading databases from historical dump files. If so, then 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?

>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. Then only
old-style functions would break as per your example (I dislike the idea of
the language changing when it is just the interface we modify).

In the even longer term, maybe the function manager should be able to
interrogate functions when they are first loaded, and ask them about the
interface they expect to use.

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