Re: [rfc] new CREATE FUNCTION (and more)
От | Marko Kreen |
---|---|
Тема | Re: [rfc] new CREATE FUNCTION (and more) |
Дата | |
Msg-id | 20001117041109.B10861@l-t.ee обсуждение исходный текст |
Ответ на | Re: [rfc] new CREATE FUNCTION (and more) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Thu, Nov 16, 2000 at 08:06:30PM -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); > > Datum > foo(PG_FUNCTION_ARGS) > { > ... > } > > to create a dynamically loadable new-style function. > > Comments? I like it :) e.g. struct pg_function_info_header { int api_ver;}; and PG_FUNCTION_TAG(foo); expands to struct pg_function_info_header __pg_function_foo_info = { 0 }; so when we sometimes get around to add more fields to it we increase the api_ver. For more info also the macros will be different. This _TAG means "no info is given it is only tagged as newC". Comments? -- marko
В списке pgsql-hackers по дате отправления: