Peter Eisentraut <peter_e@gmx.net> writes:
> On 5/12/14, 12:42 PM, Tom Lane wrote:
>> Peter Eisentraut <peter_e@gmx.net> writes:
>>> You need plv8 master branch (unreleased), which fixes all these issues.
>> How does it deal with the function declaration incompatibility problem?
> commit df92ced297282ffbb13e95748543b6c52ad4d238
> Author: Hitoshi Harada <umi.tanuki@gmail.com>
> Date: Wed May 7 01:28:18 2014 -0700
> Remove exception specifier from PG callbacks.
> 9.4 includes function declaration in PG_FUNCTION_INFO_V1 macro, which is
> not compatible with ours using exception specifiers. Actually I don't
> see the reason we have them so simply I remove them.
> That said, I'm not yet sure what the overall right answer is here.
Hm. If you're writing SQL functions in C++, you definitely don't want
them throwing any C++ exceptions out to the core backend; so the throw()
declaration is sensible and might help catch coding errors. That means
that Hitoshi-san's solution is just a quick hack rather than a desirable
answer.
We could perhaps use an "#ifdef __cplusplus" in the declaration of
PG_FUNCTION_INFO_V1 to forcibly put a "throw()" into the extern when
compiling C++. That would break less-carefully-written C++ code, but
the fix would be easy (unless they are throwing exceptions, but then
they've got a bug to fix anyway).
I'm concerned though that this may not be the only use-case for
decorations on those externs. A slightly more flexible answer
is to make it look like
#ifdef __cplusplus
#define PG_FUNCTION_DECORATION throw()
#else
#define PG_FUNCTION_DECORATION
#endif
#define PG_FUNCTION_INFO_V1(funcname) \
Datum funcname(PG_FUNCTION_ARGS) PG_FUNCTION_DECORATION; \
extern ...
which would leave the door open for modules to redefine
PG_FUNCTION_DECORATION if they had to. On the other hand it could
reasonably be argued that that would largely break the point of
having a uniform extern declaration in the first place.
Still wondering if we shouldn't just revert this change as being more
pain than gain.
regards, tom lane
