Re: Writing triggers in C++ - Mailing list pgsql-hackers

Florian G. Pflug wrote:
> Alvaro Herrera wrote:
> >Florian G. Pflug wrote:
> >>Andreas Pflug wrote:
> >>>Tom Lane wrote:
> >>>>Jacob Rief <jacob.rief@gmx.at> 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 Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support