Re: cannot to compile PL/V8 on Fedora 20

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On 5/12/14, 12:42 PM, Tom Lane wrote:
>> Peter Eisentraut <peter_e(at)gmx(dot)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(dot)tanuki(at)gmail(dot)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