Re: [HACKERS] cannot to compile PL/V8 on Fedora 20

2014-05-12 Thread Tom Lane
Peter Eisentraut  writes:
> On 5/12/14, 12:42 PM, Tom Lane wrote:
>> Peter Eisentraut  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 
> 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


Re: [HACKERS] cannot to compile PL/V8 on Fedora 20

2014-05-12 Thread Alvaro Herrera
Peter Eisentraut wrote:
> On 5/12/14, 12:42 PM, Tom Lane wrote:
> > Peter Eisentraut  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 
> 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.

Do C++ exception specifiers in fmgr V1 functions work at all?

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] cannot to compile PL/V8 on Fedora 20

2014-05-12 Thread Peter Eisentraut
On 5/12/14, 12:42 PM, Tom Lane wrote:
> Peter Eisentraut  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 
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.



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] cannot to compile PL/V8 on Fedora 20

2014-05-12 Thread Tom Lane
Peter Eisentraut  writes:
> You need plv8 master branch (unreleased), which fixes all these issues.

How does it deal with the function declaration incompatibility problem?

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


Re: [HACKERS] cannot to compile PL/V8 on Fedora 20

2014-05-12 Thread Pavel Stehule
2014-05-12 18:36 GMT+02:00 Peter Eisentraut :

> On 5/12/14, 11:05 AM, Pavel Stehule wrote:
> > After returning back before this commit I cannot compile PL/V8 still but
> > with more solvable bug
> >
> >  g++ -Wall -O2  -I. -I./ -I/usr/local/pgsql/include/server
> > -I/usr/local/pgsql/include/internal -D_GNU_SOURCE
> > -I/usr/include/libxml2  -fPIC -c -o plv8.o plv8.cc
> > g++ -Wall -O2  -I. -I./ -I/usr/local/pgsql/include/server
> > -I/usr/local/pgsql/include/internal -D_GNU_SOURCE
> > -I/usr/include/libxml2  -fPIC -c -o plv8_type.o plv8_type.cc
> > g++ -Wall -O2  -I. -I./ -I/usr/local/pgsql/include/server
> > -I/usr/local/pgsql/include/internal -D_GNU_SOURCE
> > -I/usr/include/libxml2  -fPIC -c -o plv8_func.o plv8_func.cc
> > plv8_func.cc: In function ‘v8::Handle plv8_Prepare(const
> > v8::Arguments&)’:
> > plv8_func.cc:521:47: error: too few arguments to function ‘void
> > parseTypeString(const char*, Oid*, int32*, bool)’
> >parseTypeString(typestr, &types[i], &typemod);
> >^
> > In file included from plv8_func.cc:22:0:
> > /usr/local/pgsql/include/server/parser/parse_type.h:50:13: note:
> > declared here
> >  extern void parseTypeString(const char *str, Oid *typeid_p, int32
> > *typmod_p, bool missing_ok);
> >  ^
> > make: *** [plv8_func.o] Error 1
> >
> > so the main issue is really this commit
>
> You need plv8 master branch (unreleased), which fixes all these issues.
>  No released version of plv8 works with 9.4 at the moment.
>

ok, I'll check it

Thank you

Pavel


Re: [HACKERS] cannot to compile PL/V8 on Fedora 20

2014-05-12 Thread Peter Eisentraut
On 5/12/14, 11:05 AM, Pavel Stehule wrote:
> After returning back before this commit I cannot compile PL/V8 still but
> with more solvable bug
> 
>  g++ -Wall -O2  -I. -I./ -I/usr/local/pgsql/include/server
> -I/usr/local/pgsql/include/internal -D_GNU_SOURCE
> -I/usr/include/libxml2  -fPIC -c -o plv8.o plv8.cc
> g++ -Wall -O2  -I. -I./ -I/usr/local/pgsql/include/server
> -I/usr/local/pgsql/include/internal -D_GNU_SOURCE
> -I/usr/include/libxml2  -fPIC -c -o plv8_type.o plv8_type.cc
> g++ -Wall -O2  -I. -I./ -I/usr/local/pgsql/include/server
> -I/usr/local/pgsql/include/internal -D_GNU_SOURCE
> -I/usr/include/libxml2  -fPIC -c -o plv8_func.o plv8_func.cc
> plv8_func.cc: In function ‘v8::Handle plv8_Prepare(const
> v8::Arguments&)’:
> plv8_func.cc:521:47: error: too few arguments to function ‘void
> parseTypeString(const char*, Oid*, int32*, bool)’
>parseTypeString(typestr, &types[i], &typemod);
>^
> In file included from plv8_func.cc:22:0:
> /usr/local/pgsql/include/server/parser/parse_type.h:50:13: note:
> declared here
>  extern void parseTypeString(const char *str, Oid *typeid_p, int32
> *typmod_p, bool missing_ok);
>  ^
> make: *** [plv8_func.o] Error 1
> 
> so the main issue is really this commit

You need plv8 master branch (unreleased), which fixes all these issues.
 No released version of plv8 works with 9.4 at the moment.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] cannot to compile PL/V8 on Fedora 20

2014-05-12 Thread Pavel Stehule
2014-05-12 16:31 GMT+02:00 Tom Lane :

> Andrew Dunstan  writes:
> > On 05/12/2014 07:10 AM, Pavel Stehule wrote:
> >> I am trying to compile PL/v8 without success. I have Postgres
> >> installed via compilation from source code.
>
> >> plv8.cc:50:56: error: declaration of ‘Datum
> >> plv8_call_handler(FunctionCallInfo) throw ()’ has a different
> >> exception specifier
> >> Datum plv8_call_handler(PG_FUNCTION_ARGS) throw();
> >> ^
> >> plv8.cc:43:7: error: from previous declaration ‘Datum
> >> plv8_call_handler(FunctionCallInfo)’
> >> PG_FUNCTION_INFO_V1(plv8_call_handler);
>
> > This looks like a result of commit
> > <
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=e7128e8dbb305059c30ec085461297e619bcbff4
> >
>
> Ouch.  I was a bit suspicious of that change from the start, but it hadn't
> occurred to me that functions written in C++ would have an issue with it.
>
> > Maybe we need a way of telling the preprocessor to suppress the
> > generation of a prototype?
>
> Maybe we need to revert that patch altogether.  Dealing with this is
> likely to introduce much more pain and confusion than the change is worth.
>

After returning back before this commit I cannot compile PL/V8 still but
with more solvable bug

 g++ -Wall -O2  -I. -I./ -I/usr/local/pgsql/include/server
-I/usr/local/pgsql/include/internal -D_GNU_SOURCE -I/usr/include/libxml2
-fPIC -c -o plv8.o plv8.cc
g++ -Wall -O2  -I. -I./ -I/usr/local/pgsql/include/server
-I/usr/local/pgsql/include/internal -D_GNU_SOURCE -I/usr/include/libxml2
-fPIC -c -o plv8_type.o plv8_type.cc
g++ -Wall -O2  -I. -I./ -I/usr/local/pgsql/include/server
-I/usr/local/pgsql/include/internal -D_GNU_SOURCE -I/usr/include/libxml2
-fPIC -c -o plv8_func.o plv8_func.cc
plv8_func.cc: In function ‘v8::Handle plv8_Prepare(const
v8::Arguments&)’:
plv8_func.cc:521:47: error: too few arguments to function ‘void
parseTypeString(const char*, Oid*, int32*, bool)’
   parseTypeString(typestr, &types[i], &typemod);
   ^
In file included from plv8_func.cc:22:0:
/usr/local/pgsql/include/server/parser/parse_type.h:50:13: note: declared
here
 extern void parseTypeString(const char *str, Oid *typeid_p, int32
*typmod_p, bool missing_ok);
 ^
make: *** [plv8_func.o] Error 1

so the main issue is really this commit

Regards

Pavel

p.s. my tests on 9.2 was messy probably





>
> regards, tom lane
>


Re: [HACKERS] cannot to compile PL/V8 on Fedora 20

2014-05-12 Thread Tom Lane
Andrew Dunstan  writes:
> On 05/12/2014 07:10 AM, Pavel Stehule wrote:
>> I am trying to compile PL/v8 without success. I have Postgres 
>> installed via compilation from source code.

>> plv8.cc:50:56: error: declaration of ‘Datum 
>> plv8_call_handler(FunctionCallInfo) throw ()’ has a different 
>> exception specifier
>> Datum plv8_call_handler(PG_FUNCTION_ARGS) throw();
>> ^
>> plv8.cc:43:7: error: from previous declaration ‘Datum 
>> plv8_call_handler(FunctionCallInfo)’
>> PG_FUNCTION_INFO_V1(plv8_call_handler);

> This looks like a result of commit 
> 
>  

Ouch.  I was a bit suspicious of that change from the start, but it hadn't
occurred to me that functions written in C++ would have an issue with it.

> Maybe we need a way of telling the preprocessor to suppress the 
> generation of a prototype?

Maybe we need to revert that patch altogether.  Dealing with this is
likely to introduce much more pain and confusion than the change is worth.

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


Re: [HACKERS] cannot to compile PL/V8 on Fedora 20

2014-05-12 Thread Pavel Stehule
2014-05-12 15:42 GMT+02:00 Andrew Dunstan :

>
> On 05/12/2014 07:10 AM, Pavel Stehule wrote:
>
>> Hello
>>
>> I am trying to compile PL/v8 without success. I have Postgres installed
>> via compilation from source code.
>>
>> After make I got errors
>>
>> [pavel@localhost plv8-1.4.2]$ make
>> g++ -Wall -O2  -I. -I./ -I/usr/local/pgsql/include/server
>> -I/usr/local/pgsql/include/internal -D_GNU_SOURCE -I/usr/include/libxml2
>>  -fPIC -c -o plv8.o plv8.cc
>> plv8.cc:50:56: error: declaration of ‘Datum 
>> plv8_call_handler(FunctionCallInfo)
>> throw ()’ has a different exception specifier
>>  Datum plv8_call_handler(PG_FUNCTION_ARGS) throw();
>> ^
>> plv8.cc:43:7: error: from previous declaration ‘Datum plv8_call_handler(
>> FunctionCallInfo)’
>>  PG_FUNCTION_INFO_V1(plv8_call_handler);
>>
>
> This looks like a result of commit  gitweb/?p=postgresql.git;a=commitdiff;h=e7128e8dbb305059c30ec085461297
> e619bcbff4> Maybe we need a way of telling the preprocessor to suppress
> the generation of a prototype?
>

I got same result with tarball 9.2.4 released 2014-04-04

Pavel


>
> cheers
>
> andrew
>
>


Re: [HACKERS] cannot to compile PL/V8 on Fedora 20

2014-05-12 Thread Andrew Dunstan


On 05/12/2014 07:10 AM, Pavel Stehule wrote:

Hello

I am trying to compile PL/v8 without success. I have Postgres 
installed via compilation from source code.


After make I got errors

[pavel@localhost plv8-1.4.2]$ make
g++ -Wall -O2  -I. -I./ -I/usr/local/pgsql/include/server 
-I/usr/local/pgsql/include/internal -D_GNU_SOURCE 
-I/usr/include/libxml2  -fPIC -c -o plv8.o plv8.cc
plv8.cc:50:56: error: declaration of ‘Datum 
plv8_call_handler(FunctionCallInfo) throw ()’ has a different 
exception specifier

 Datum plv8_call_handler(PG_FUNCTION_ARGS) throw();
^
plv8.cc:43:7: error: from previous declaration ‘Datum 
plv8_call_handler(FunctionCallInfo)’

 PG_FUNCTION_INFO_V1(plv8_call_handler);


This looks like a result of commit 
 
Maybe we need a way of telling the preprocessor to suppress the 
generation of a prototype?


cheers

andrew



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] cannot to compile PL/V8 on Fedora 20

2014-05-12 Thread Pavel Stehule
2014-05-12 13:45 GMT+02:00 Michael Paquier :

> On Mon, May 12, 2014 at 8:10 PM, Pavel Stehule 
> wrote:
> > g++ -Wall -O2  -I. -I./ -I/usr/local/pgsql/include/server
> > -I/usr/local/pgsql/include/internal -D_GNU_SOURCE -I/usr/include/libxml2
> > -fPIC -c -o plv8.o plv8.cc
> > plv8.cc:50:56: error: declaration of 'Datum
> > plv8_call_handler(FunctionCallInfo) throw ()' has a different exception
> > specifier
> >  Datum plv8_call_handler(PG_FUNCTION_ARGS) throw();
> > Some ideas how to fix it?
> It seems that you are compiling on the outdated branch staticlink. On
> either master or r1.4 it will work properly on Fedora 20, at least it
> works for me.
>

How I can check it?

I had same bug with scientific linux and I expected so this problem will be
solved on new Fedora. On second computer on newer system I had same problem.

Some problem can be in my g++ environment - it is default Fedora.

Pavel


> --
> Michael
>


Re: [HACKERS] cannot to compile PL/V8 on Fedora 20

2014-05-12 Thread Michael Paquier
On Mon, May 12, 2014 at 8:10 PM, Pavel Stehule  wrote:
> g++ -Wall -O2  -I. -I./ -I/usr/local/pgsql/include/server
> -I/usr/local/pgsql/include/internal -D_GNU_SOURCE -I/usr/include/libxml2
> -fPIC -c -o plv8.o plv8.cc
> plv8.cc:50:56: error: declaration of 'Datum
> plv8_call_handler(FunctionCallInfo) throw ()' has a different exception
> specifier
>  Datum plv8_call_handler(PG_FUNCTION_ARGS) throw();
> Some ideas how to fix it?
It seems that you are compiling on the outdated branch staticlink. On
either master or r1.4 it will work properly on Fedora 20, at least it
works for me.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers