Re: [rfc] new CREATE FUNCTION (and more)

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: [rfc] new CREATE FUNCTION (and more)
Дата
Msg-id
11137.974426900@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
[rfc] new CREATE FUNCTION (and more) Marko Kreen <marko@l-t.ee>
Re: [rfc] new CREATE FUNCTION (and more) Tom Lane <tgl@sss.pgh.pa.us>
Re: [rfc] new CREATE FUNCTION (and more) Nathan Myers <ncm@zembu.com>
Re: [rfc] new CREATE FUNCTION (and more) Tom Lane <tgl@sss.pgh.pa.us>
Re: [rfc] new CREATE FUNCTION (and more) Marko Kreen <marko@l-t.ee>
Re: [rfc] new CREATE FUNCTION (and more) Philip Warner <pjw@rhyme.com.au>
Re: [rfc] new CREATE FUNCTION (and more) Tom Lane <tgl@sss.pgh.pa.us>
Re: [rfc] new CREATE FUNCTION (and more) Philip Warner <pjw@rhyme.com.au>
Re: [rfc] new CREATE FUNCTION (and more) Tom Lane <tgl@sss.pgh.pa.us>
Re: [rfc] new CREATE FUNCTION (and more) Philip Warner <pjw@rhyme.com.au>
Re: [rfc] new CREATE FUNCTION (and more) Tom Lane <tgl@sss.pgh.pa.us>
Re: [rfc] new CREATE FUNCTION (and more) Philip Warner <pjw@rhyme.com.au>
Re: [rfc] new CREATE FUNCTION (and more) Tom Lane <tgl@sss.pgh.pa.us>
Re: [rfc] new CREATE FUNCTION (and more) Philip Warner <pjw@rhyme.com.au>
Re: [rfc] new CREATE FUNCTION (and more) Bruce Momjian <pgman@candle.pha.pa.us>
Re: [rfc] new CREATE FUNCTION (and more) Marko Kreen <marko@l-t.ee>
Philip Warner  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 по дате отправления
От: Bruce Momjian
Дата:
Сообщение: Re: coding style guidelines?
От: Tatsuo Ishii
Дата:
FAQ