At 20:06 16/11/00 -0500, Tom Lane wrote:
>Nathan Myers <ncm@zembu.com> writes:
>> - Keep the name 'C' for both old-style and new-style module declarations.
>> - Require that new-style modules define a distinguished symbol, such as
>> "int __postgresql_call_7_1;".
>
>I was thinking along the same lines myself. I'd want to do it on a
>per-function basis, though, rather than assuming that all functions in
>a module must use the same interface.
>
>I'd be inclined to define a macro that creates the signal object,
>so that you'd write something like
>
>PG_FUNCTION_API_V2(foo);
This sounds perfect. Would you generate an 'info' function to return a list
of entry points, or just use dummy object names? The info function has the
advantage that it can return version information as well, and a clutter of
dummy entry points might look a little messy.
I had been thinking along the lines of a generic extensible interface using
a known function, but by using macros you can even hide that layer, making
whatever we do now completely compatible.
What's also cute, is if the underlying method is designed carefully you may
be able to get one library working with multiple interfaces, especially if
the stuff that comes with PG_FUNCTION_ARGS can also provide version
information.
----------------------------------------------------------------
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 |/
