Re: STL problem in stored procedures

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: STL problem in stored procedures
Дата
Msg-id 13972.1130251448@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: STL problem in stored procedures  (Kevin Murphy <murphy@genome.chop.edu>)
Ответы Re: STL problem in stored procedures  (Andreas Seltenreich <andreas+pg@gate450.dyndns.org>)
Список pgsql-general
Kevin Murphy <murphy@genome.chop.edu> writes:
> Tom Lane wrote:
>> I think he needs to rewrite in C :-(.  The backend is not C++ and I
>> fear it's unlikely that libc++ will play nicely as a dynamic add-on.

> It would be great if some C++/C guru could make a thorough analysis of
> C++ integration issues.

The main thing that scares me is lack of integration of C error handling
(setjmp/longjmp) with C++ error handling (catch/throw).  In a
self-contained module you could perhaps avoid this by not using
catch/throw, but I don't think you get to ignore the issue if you are
using STL modules.

It *might* work to put a generic "catch/report via elog" handler around
each one of your entry-point functions.  Haven't tried it.

This all assumes that libc++ can cooperate with, rather than try to
replace, libc in the first place.  That would depend a lot on what
platform you are on --- I think it might work OK with modern glibc,
but my last experience with C++ was back when it wasn't so.

            regards, tom lane

В списке pgsql-general по дате отправления:

Предыдущее
От: Kevin Murphy
Дата:
Сообщение: Re: STL problem in stored procedures
Следующее
От: Michael Fuhr
Дата:
Сообщение: Re: STL problem in stored procedures