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

At 21:08 16/11/00 -0500, Tom Lane wrote:
>Philip Warner <pjw(at)rhyme(dot)com(dot)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);
...
>
>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; }
>

For possible future compatibility, can you also do something like:

PG_FUNCTION_API_V2;
PG_FUNCTION_V2(foo);
PG_FUNCTION_V2(bar);
...

Where

PG_FUNCTION_API_V2 expands to:

int pg_fmgr_api_version(void) { return 2; }

And PG_FUNCTION_V2(foo) either does nothing or expands to:

int pg_fmgr_api2_version_foo(void) { return 2; }

The first call will tell PG that (because it is version 2), it should
expect the next set of entry points. Since we will not be allowing mixed
versions in this version of the API (I think), we could really have the
subsequent macros do nothing.

This way we make it more independant of future API versions by not
requiring a specific special entry point for each function. Then can do
things like use the same entry point for multiple functions, possibly act
as stubs pointing to other libraries (by loading & returning another
library entry point) etc etc.

>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.

In the plans for PG_FUNCTION_API_V3(?), I actually have the info function
returning a struct with values for 'iscacheable', 'isstrict', and the
actual entry point to use. This reduces duplication since the programmer is
the best person to know these attributes. But using macros is fine:

PG_FUNCTION_API_V3 expand to:

typedef struct {bool iscacheable, bool isstrict, ptr entrypoint }
pg_fmgr_info;
int pg_fmgr_api_version(void) { return 3; }

and

PG_FUNCTION_V3(foo, false, true, foo_entry_point)

expand to:

void pg_fmgr_api_version_foo(fmgr_info *i)
{ i->iscacheable=false;
i->isstrict=true;
i->entrypoint=foo_entry_point; }

will work as well.

Perhaps in PG_FUNCTION_API_V4 we can implement some kind of interface for
listing supported entry points for module loading...

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/