Re: STL problem in stored procedures

Andreas Seltenreich <andreas+pg(at)gate450(dot)dyndns(dot)org> writes:
> Tom Lane schrob:
>> It *might* work to put a generic "catch/report via elog" handler around
>> each one of your entry-point functions. Haven't tried it.

> Hmm, this setup worked quite stable here for some smaller educational
> projects. The snippet I used to wrap the C++ was:
> [ snip ]
> [ some later mention of calling back into the backend for, eg, palloc ]

I was with you until that last bit. Have you covered the case where
palloc or another called-back backend routine throws an elog? AFAICS
the only clean way to do that is to PG_TRY around every such call,
throw the error as a C++ throw, catch it again at the function exit
level, re-throw as a PG longjmp :-(. Aside from the sheer tedium and
error-proneness, there's the certainty of losing quite a lot of semantic
detail in the error reports. And on top of that, what if the error was
one that the backend can't recover from except by a transaction abort?
If some level of the C++ code thinks it can catch and recover from the
error, you've left things in a pretty bad state. (palloc failure
doesn't have this risk, but a lot of other error conditions do.)

regards, tom lane