Re: [rfc] new CREATE FUNCTION (and more)
От | Tom Lane |
---|---|
Тема | Re: [rfc] new CREATE FUNCTION (and more) |
Дата | |
Msg-id | 11137.974426900@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [rfc] new CREATE FUNCTION (and more) (Philip Warner <pjw@rhyme.com.au>) |
Ответы |
Re: [rfc] new CREATE FUNCTION (and more)
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: