Re: cannot to compile PL/V8 on Fedora 20 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: cannot to compile PL/V8 on Fedora 20
Date
Msg-id 25823.1399915909@sss.pgh.pa.us
Whole thread Raw
In response to Re: cannot to compile PL/V8 on Fedora 20  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: cannot to compile PL/V8 on Fedora 20
Next
From: Fujii Masao
Date:
Subject: Re: Compression of full-page-writes