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

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

In response to

Browse pgsql-hackers by date

  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)