Peter Eisentraut <pete...@gmx.net> writes: > On 5/12/14, 12:42 PM, Tom Lane wrote: >> Peter Eisentraut <pete...@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.tan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers