Re: [HACKERS] Writing triggers in C++

[Jacob Rief]

Tom Lane wrote:

> That is most likely not going to work anyway, because the backend
> operating environment is C not C++.  If you dumb it down enough
> --- no exceptions, no RTTI, no use of C++ library --- then it might
> work, but at that point you're really coding in C anyway.

Writing "normal" user-defined-functions in C++ is not a problem so far.
I even handle C++ exceptions, by catching each C++ exception inside my
functions. The catch()-blocks in those functions raise
Postgres-exceptions using elog in case of a throw(). Writing "normal"
user-defined-functions in C++ is even encouraged by the documentation,
which says: "User-defined functions can be written in C (or a language
that can be made compatible with C, such as C++)." [chapter 33.9.]
The question is, why not writing user-defined trigger-functions in 
C++ ? The difference between a "normal" function and a trigger function
is not that big although. The "big" difference is, that one must include
some more header-files (executor/spi.h and commands/trigger.h) which
themselves include other headers-files containing identifiers which
unfortunately are C++-keywords.

> > Is there any convention how to rename such identifiers? If I would
> > rename those identifiers (I simply would add an underscore to each of
> > them), would such a patch be accepted and adopted onto one of the next
> > releases? 
> 
> No.  Because of the above problems, we don't see much reason to avoid
> C++'s extra keywords.

In order to check how much code would be have to be changed, I renamed
the affected keywords in the Postgres-8.2.3-headers files, patched the
affected sources and recompiled the code. The resulting patch affects
only 189 lines of code in 23 files.
Applying this patch would encourage authors of external trigger
functions to write their code in C++ instead of using PL/SQL and calling
"normal" user-defined functions, or writing wrappers in C to hide the 
C++-keywords.
I will recreate this patch for the CVS-head of the repository, if there
are chances that it ever will be commitet.

Regards, Jacob



---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] Writing triggers in C++

[bjarne]

On Feb 14, 11:26 am, [EMAIL PROTECTED] ("Florian G. Pflug") wrote:
> Neil Conway wrote:
> > On Wed, 2007-02-14 at 13:19 -0300, Alvaro Herrera wrote:
> >> Probably stack allocation doesn't matter much, as I think that would be
> >> unwinded by the longjmp call.  I don't know a lot about C++, but if
> >> there are allocations in the data area then those would probably not be
> >> freed.  But it makes me wonder -- is longjmp very compatible with C++
> >> exceptions at all?
>
> > "C-style stack unwinding (using setjmp and longjmp from ) is
> > incompatible with exception-handling and is best avoided." (Stroustrup,
> > p. 433).
>
> > Which presumably means that in practice, the interaction between these
> > features is implementation-defined.
>
> Well, as long as you don't longjmp "past" an C++ catch block, and don't
> throw an C++ exception "past" an setjmp handler, there should be no
> problem I think. Or at least I can't imagine how a problem could arise..
>

Also, don't jump out of (past) the scope of any local variable with a
destructor.

If you are in a C++ program, use exceptions. If you are in a C
program, fake the equivalent using setjmp/longjmp. Don't mix the two -
it's too tricky.

  -- Bjarne Stroustrup; http://www.research.att.com/~bs


---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] Writing triggers in C++

[Andreas Seltenreich]

Florian G. Pflug writes:

>>> Maybe we should create some wiki page or pgfoundry project that collects
>>> all glue code, tipps and tricks that people invented to glue C++ into
>>> the postgres backend.
>>
>> If it can be made to work, sure; in techdocs.
>
> I was thinking that two pairs of macros,
> PG_BEGIN_CPP, PG_END_CPP and
> PG_CPP_BEGIN_BACKEND, PG_CPP_END_BACKEND
> should be able to take care of the exception handling issues.
>
> You'd need to wrap any code-block that calls postgres functions that
> might do an elog(ERROR) inside PG_CPP_BEGIN_BACKEND,
> PG_CPP_END_BACKEND.
>
> Vice versa, any block of c++ code that is called from the backend would
> need to start with PG_BEGIN_CPP, and end with PG_END_CPP.

I've made positive experiences with such a setup, although I've spared
the PG_BEGIN_CPP/PG_END_CPP by doing the exception conversion in a C++
language handler that instantiates functors using the portable class
loading technique described in this paper:



I'd be glad to help out on a pgfoundry project to make C++ a better
citizen for extending postgres.

regards,
andreas

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] Writing triggers in C++

[Florian G. Pflug]

Neil Conway wrote:

On Wed, 2007-02-14 at 13:19 -0300, Alvaro Herrera wrote:

Probably stack allocation doesn't matter much, as I think that would be
unwinded by the longjmp call.  I don't know a lot about C++, but if
there are allocations in the data area then those would probably not be
freed.  But it makes me wonder -- is longjmp very compatible with C++
exceptions at all?


"C-style stack unwinding (using setjmp and longjmp from ) is
incompatible with exception-handling and is best avoided." (Stroustrup,
p. 433).

Which presumably means that in practice, the interaction between these
features is implementation-defined.


Well, as long as you don't longjmp "past" an C++ catch block, and don't
throw an C++ exception "past" an setjmp handler, there should be no 
problem I think. Or at least I can't imagine how a problem could arise..


greetings, Florian Pflug

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq

Re: [HACKERS] Writing triggers in C++

[Florian G. Pflug]

Alvaro Herrera wrote:

Florian G. Pflug wrote:

Alvaro Herrera wrote:

Florian G. Pflug wrote:

Andreas Pflug wrote:

Tom Lane wrote:

Jacob Rief <[EMAIL PROTECTED]> writes:


I tried to write a trigger using C++.
  

That is most likely not going to work anyway, because the backend
operating environment is C not C++.  If you dumb it down enough
--- no exceptions, no RTTI, no use of C++ library --- then it might
work, 

I can confirm that it does work this way.
I've written an aggregate function that uses c++ stl hashes, and it 
seems to work pretty well. I'd think that using exceptions should be

fine, as long as you make sure to _always_ catch any exception that
might be thrown inside your own c++ code, and don't let it propagate
into backend code. STL allows you to specify custom allocator classes
as template parameters to hash, vector and the like. You can use that
to let STL allocate memory from the correct memory context.

What happens if Postgres raises an elog(ERROR) in the code you're
catching exceptions in?  Is it propagated outwards?
In my case, the only possible source of an elog(ERROR) would palloc(), 
when the machine is out of memory (Does it even throw elog(ERROR), or

does it return NULL just as malloc() ?). Since this is rather unlikely,
and would probably lead to a postgres shutdown anyway, I didn't really
care about that case.


No, an out-of-memory leads to elog(ERROR), which rolls back the current
transaction.  This releases some memory so the system can continue
working.  In fact we periodically see out-of-memory reports, and they
certainly _don't_ cause a general shutdown.


Sorry, I explained my point badly. What I actually meant is that in my
specific use-case (Lots of small transaction, non of which use much 
memory), the only reason for out-of-memory conditions I've even seen
was some application gone wild that ate up all available memory. In that 
case, postgres dies sooner or later, because any memory freed during 
rollback is immediatly used by that other application. In general, of 
course, you're right.


You're right of course that this is different for triggers - they're 
much more likely to call SPI functions or otherwise interact with the
backend than my rather self-contained aggregate function. Still, I'd 
think that an elog(ERROR) would propagate outwards - but any C++

destructors of local (stack-allocated) objects wouldn't be called.


Probably stack allocation doesn't matter much, as I think that would be
unwinded by the longjmp call.  I don't know a lot about C++, but if
there are allocations in the data area then those would probably not be
freed.  But it makes me wonder -- is longjmp very compatible with C++
exceptions at all?  I know that it causes problems with POSIX thread
cancel_push() and cancel_pop() for example (meaning, they can't be
used).


Yeah, the memory taken by stack-allocated objects is freed (basically by
just resetting the stack pointer). But normally, C++ would call the 
destructor of a stack-allocated objects _before_ resetting the 
stack-pointer. Since setjmp/longjmp don't know anything about C++, they

will omit this step. Whether this causes problems or not depends on the
objects that you allocated on the stack...


So, to be safe, I guess one would need to surround any call that could
call elog(ERROR) with an appropriate handler that translates the 
elog(ERROR) into a C++ exception. This C++ exception would have to be

translated back into an elog(ERROR) at the outmost level of C++ code.


Sort of a PG_RE_THROW() in the exception handler, I guess.


Maybe we should create some wiki page or pgfoundry project that collects
all glue code, tipps and tricks that people invented to glue C++ into
the postgres backend.


If it can be made to work, sure; in techdocs.


I was thinking that two pairs of macros,
PG_BEGIN_CPP, PG_END_CPP and
PG_CPP_BEGIN_BACKEND, PG_CPP_END_BACKEND
should be able to take care of the exception handling issues.

You'd need to wrap any code-block that calls postgres functions that 
might do an elog(ERROR) inside PG_CPP_BEGIN_BACKEND, PG_CPP_END_BACKEND.


Vice versa, any block of c++ code that is called from the backend would
need to start with PG_BEGIN_CPP, and end with PG_END_CPP.

Do you see any other possible problems, aside from memory managemt issues?

greetings, Florian Pflug


---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match

Re: [HACKERS] Writing triggers in C++

[Neil Conway]

On Wed, 2007-02-14 at 13:19 -0300, Alvaro Herrera wrote:
> Probably stack allocation doesn't matter much, as I think that would be
> unwinded by the longjmp call.  I don't know a lot about C++, but if
> there are allocations in the data area then those would probably not be
> freed.  But it makes me wonder -- is longjmp very compatible with C++
> exceptions at all?

"C-style stack unwinding (using setjmp and longjmp from ) is
incompatible with exception-handling and is best avoided." (Stroustrup,
p. 433).

Which presumably means that in practice, the interaction between these
features is implementation-defined.

-Neil



---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] Writing triggers in C++

[Alvaro Herrera]

Florian G. Pflug wrote:
> Alvaro Herrera wrote:
> >Florian G. Pflug wrote:
> >>Andreas Pflug wrote:
> >>>Tom Lane wrote:
> Jacob Rief <[EMAIL PROTECTED]> writes:
>  
> >I tried to write a trigger using C++.
> >   
> That is most likely not going to work anyway, because the backend
> operating environment is C not C++.  If you dumb it down enough
> --- no exceptions, no RTTI, no use of C++ library --- then it might
> work, 
> >>>I can confirm that it does work this way.
> >>I've written an aggregate function that uses c++ stl hashes, and it 
> >>seems to work pretty well. I'd think that using exceptions should be
> >>fine, as long as you make sure to _always_ catch any exception that
> >>might be thrown inside your own c++ code, and don't let it propagate
> >>into backend code. STL allows you to specify custom allocator classes
> >>as template parameters to hash, vector and the like. You can use that
> >>to let STL allocate memory from the correct memory context.
> >
> >What happens if Postgres raises an elog(ERROR) in the code you're
> >catching exceptions in?  Is it propagated outwards?
> 
> In my case, the only possible source of an elog(ERROR) would palloc(), 
> when the machine is out of memory (Does it even throw elog(ERROR), or
> does it return NULL just as malloc() ?). Since this is rather unlikely,
> and would probably lead to a postgres shutdown anyway, I didn't really
> care about that case.

No, an out-of-memory leads to elog(ERROR), which rolls back the current
transaction.  This releases some memory so the system can continue
working.  In fact we periodically see out-of-memory reports, and they
certainly _don't_ cause a general shutdown.

> You're right of course that this is different for triggers - they're 
> much more likely to call SPI functions or otherwise interact with the
> backend than my rather self-contained aggregate function. Still, I'd 
> think that an elog(ERROR) would propagate outwards - but any C++
> destructors of local (stack-allocated) objects wouldn't be called.

Probably stack allocation doesn't matter much, as I think that would be
unwinded by the longjmp call.  I don't know a lot about C++, but if
there are allocations in the data area then those would probably not be
freed.  But it makes me wonder -- is longjmp very compatible with C++
exceptions at all?  I know that it causes problems with POSIX thread
cancel_push() and cancel_pop() for example (meaning, they can't be
used).

> So, to be safe, I guess one would need to surround any call that could
> call elog(ERROR) with an appropriate handler that translates the 
> elog(ERROR) into a C++ exception. This C++ exception would have to be
> translated back into an elog(ERROR) at the outmost level of C++ code.

Sort of a PG_RE_THROW() in the exception handler, I guess.

> Maybe we should create some wiki page or pgfoundry project that collects
> all glue code, tipps and tricks that people invented to glue C++ into
> the postgres backend.

If it can be made to work, sure; in techdocs.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Writing triggers in C++

[Florian G. Pflug]

Alvaro Herrera wrote:

Florian G. Pflug wrote:

Andreas Pflug wrote:

Tom Lane wrote:

Jacob Rief <[EMAIL PROTECTED]> writes:
 

I tried to write a trigger using C++.
   

That is most likely not going to work anyway, because the backend
operating environment is C not C++.  If you dumb it down enough
--- no exceptions, no RTTI, no use of C++ library --- then it might
work, 

I can confirm that it does work this way.
I've written an aggregate function that uses c++ stl hashes, and it 
seems to work pretty well. I'd think that using exceptions should be

fine, as long as you make sure to _always_ catch any exception that
might be thrown inside your own c++ code, and don't let it propagate
into backend code. STL allows you to specify custom allocator classes
as template parameters to hash, vector and the like. You can use that
to let STL allocate memory from the correct memory context.


What happens if Postgres raises an elog(ERROR) in the code you're
catching exceptions in?  Is it propagated outwards?


In my case, the only possible source of an elog(ERROR) would palloc(), 
when the machine is out of memory (Does it even throw elog(ERROR), or

does it return NULL just as malloc() ?). Since this is rather unlikely,
and would probably lead to a postgres shutdown anyway, I didn't really
care about that case.

You're right of course that this is different for triggers - they're 
much more likely to call SPI functions or otherwise interact with the
backend than my rather self-contained aggregate function. Still, I'd 
think that an elog(ERROR) would propagate outwards - but any C++

destructors of local (stack-allocated) objects wouldn't be called.

So, to be safe, I guess one would need to surround any call that could
call elog(ERROR) with an appropriate handler that translates the 
elog(ERROR) into a C++ exception. This C++ exception would have to be

translated back into an elog(ERROR) at the outmost level of C++ code.

Maybe we should create some wiki page or pgfoundry project that collects
all glue code, tipps and tricks that people invented to glue C++ into
the postgres backend.

greetings, Florian Pflug


---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org

Re: [HACKERS] Writing triggers in C++

[Alvaro Herrera]

Florian G. Pflug wrote:
> Andreas Pflug wrote:
> >Tom Lane wrote:
> >>Jacob Rief <[EMAIL PROTECTED]> writes:
> >>  
> >>>I tried to write a trigger using C++.
> >>>
> >>That is most likely not going to work anyway, because the backend
> >>operating environment is C not C++.  If you dumb it down enough
> >>--- no exceptions, no RTTI, no use of C++ library --- then it might
> >>work, 
> >I can confirm that it does work this way.
> 
> I've written an aggregate function that uses c++ stl hashes, and it 
> seems to work pretty well. I'd think that using exceptions should be
> fine, as long as you make sure to _always_ catch any exception that
> might be thrown inside your own c++ code, and don't let it propagate
> into backend code. STL allows you to specify custom allocator classes
> as template parameters to hash, vector and the like. You can use that
> to let STL allocate memory from the correct memory context.

What happens if Postgres raises an elog(ERROR) in the code you're
catching exceptions in?  Is it propagated outwards?

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] Writing triggers in C++

[Florian G. Pflug]

Andreas Pflug wrote:

Tom Lane wrote:

Jacob Rief <[EMAIL PROTECTED]> writes:
  

I tried to write a trigger using C++.


That is most likely not going to work anyway, because the backend
operating environment is C not C++.  If you dumb it down enough
--- no exceptions, no RTTI, no use of C++ library --- then it might
work, 

I can confirm that it does work this way.


I've written an aggregate function that uses c++ stl hashes, and it 
seems to work pretty well. I'd think that using exceptions should be

fine, as long as you make sure to _always_ catch any exception that
might be thrown inside your own c++ code, and don't let it propagate
into backend code. STL allows you to specify custom allocator classes
as template parameters to hash, vector and the like. You can use that
to let STL allocate memory from the correct memory context.

greetings, Florian Pflug

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Writing triggers in C++

[Andreas Pflug]

Tom Lane wrote:
> Jacob Rief <[EMAIL PROTECTED]> writes:
>   
>> I tried to write a trigger using C++.
>> 
>
> That is most likely not going to work anyway, because the backend
> operating environment is C not C++.  If you dumb it down enough
> --- no exceptions, no RTTI, no use of C++ library --- then it might
> work, 
I can confirm that it does work this way.

Regards,
Andreas


---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] Writing triggers in C++

[Tom Lane]

Jacob Rief <[EMAIL PROTECTED]> writes:
> I tried to write a trigger using C++.

That is most likely not going to work anyway, because the backend
operating environment is C not C++.  If you dumb it down enough
--- no exceptions, no RTTI, no use of C++ library --- then it might
work, but at that point you're really coding in C anyway.

> Is there any convention how to rename such identifiers? If I would
> rename those identifiers (I simply would add an underscore to each of
> them), would such a patch be accepted and adopted onto one of the next
> releases? 

No.  Because of the above problems, we don't see much reason to avoid
C++'s extra keywords.

regards, tom lane

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] Writing triggers in C++

[Peter Eisentraut]

Jacob Rief wrote:
> Is there any convention how to rename such identifiers? If I would
> rename those identifiers (I simply would add an underscore to each of
> them), would such a patch be accepted and adopted onto one of the
> next releases?

Couldn't you do the required renamings as preprocessor macros, e.g.,

#define typename _typename
#include 
#undef typename

#include 

your_code;


I would expect very little enthusiasm for making PostgreSQL code C++ 
safe.  There is already too much trouble keeping up with all the 
variants of C.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly