Philip Warner [EMAIL PROTECTED] writes:
Not at all. The call is, as you point out, defining the protocl for
enquiry. Nothing more. With 7.1, the process above is sufficient. There is
no need to call *in this version* because pg_fmgr_api_version returns
enough information when combined with
Nathan Myers [EMAIL PROTECTED] writes:
Why declare a function instead of a static struct?
Well, two reasons. One is that a function provides wiggle room if we
later decide that the library needs to do some computation before
handing back the function info struct. For example, Philip suggested
Marko Kreen [EMAIL PROTECTED] writes:
This mostly like the current "CREATE FUNCTION .. LANGUAGE 'C'".
Main difference is that the TYPE=0 means the old 'C' interface
and TYPE=1 means 'newC' interface. Default is 1.
This improves matters how, exactly? As far as I can see, this
Marko Kreen [EMAIL PROTECTED] writes:
This mostly like the current "CREATE FUNCTION .. LANGUAGE 'C'".
Main difference is that the TYPE=0 means the old 'C' interface
and TYPE=1 means 'newC' interface. Default is 1.
This improves matters how, exactly? As far as I can see,
At 12:59 16/11/00 -0800, Nathan Myers wrote:
- 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;".
The module loader can look for symbols that start with
On Thu, Nov 16, 2000 at 08:06:30PM -0500, Tom Lane wrote:
Nathan Myers [EMAIL PROTECTED] 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
Philip Warner [EMAIL PROTECTED] 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
At 21:08 16/11/00 -0500, Tom Lane wrote:
Philip Warner [EMAIL PROTECTED] 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
Philip Warner [EMAIL PROTECTED] writes:
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
At 22:10 16/11/00 -0500, Tom Lane wrote:
Philip Warner [EMAIL PROTECTED] writes:
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
10 matches
Mail list logo
