Philip Warner <pjw@rhyme.com.au> writes:
>> 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.
What I was thinking was that the macro would expand either to
int pg_api_foo = 2;
or
int pg_api_foo(void) { return 2; }
The former would be more compact, presumably, but the latter would
probably be more portable --- we already have to have the ability to
find and call functions in a dynamic-link library, whereas I'm not so
sure about the ability to find and read values of global variables.
In either case, the system would be able to extract an integer version
value associated with each function defined by the library. (If we
don't find the version-defining symbol, we assume old-style C API.)
Meaning of values other than "2" reserved for future definition.
I like this way better than a central info function for the whole
library, because you'd write the version declaration right with the
function itself. A central info function would be more of a pain to
maintain, I think.
regards, tom lane