From: | Marko Kreen <marko(at)l-t(dot)ee> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [rfc] new CREATE FUNCTION (and more) |
Date: | 2000-11-17 02:11:10 |
Message-ID: | 20001117041109.B10861@l-t.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 16, 2000 at 08:06:30PM -0500, Tom Lane wrote:
> Nathan Myers <ncm(at)zembu(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2000-11-17 02:28:55 | Re: [PATCHES] A Patch for MIC to EUC_TW code converting inmbsupport |
Previous Message | Tom Lane | 2000-11-17 02:08:20 | Re: [rfc] new CREATE FUNCTION (and more) |