elog in 7.4

Laszlo Hornyak <kocka@forgeahead.hu> writes:

I have a error callback function registered to run each time an SQL
error occurs. The problem is that the errfinish() calls it both if the
executed SQL statement was wrong, and if the statem,ent or plan logging
is enabled, and it seems elog.h doesn't provide the API to find out the
reason why my callback was called.

I suspect you are abusing the callback mechanism to do something it was
not intended for. Callbacks are supposed to supply information for the
error message context field, *and nothing else*. You'll probably break
things if you go outside that charter. Accordingly, I see no reason why
a callback should care why it was called.

What are you trying to accomplish, really?

regards, tom lane

Laszlo Hornyak <kocka@forgeahead.hu> writes:

I am implementing a java language handler. If unrecoverable error occurs,
it needs to send a signal to the java process, so it can stop the
execution of the stored procedure, otherwise it would stay in inconsystent
state.

Well, an elog callback is certainly the wrong place for that. Even if
it looked to see whether the elog call was ERROR or not, an ERROR is no
longer necessarily unrecoverable --- it might be caught inside a plpgsql
exception block, for example, and not really be an error at all from the
perspective of calling code.

The right way would be to use PG_TRY to catch the exception as it
propagates out to your own level of control.

regards, tom lane

Tom, is there other way in pg 7.4 than backporting PG_TRY? It seems a lot
of work.

Thanks,
Laszlo

On Tue, 21 Sep 2004, Tom Lane wrote:

On Wed, Sep 22, 2004 at 03:02:22PM +0200, Laszlo Hornyak wrote:

Tom, is there other way in pg 7.4 than backporting PG_TRY? It seems a lot
of work.

IIRC PL/Python had a hack involving sigsetjmp (which was removed in
favor of the cleaner PG_TRY). You could try doing that.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Puedes vivir solo una vez, pero si lo haces bien, una vez es suficiente"

Alvaro Herrera <alvherre@dcc.uchile.cl> writes:

On Wed, Sep 22, 2004 at 03:02:22PM +0200, Laszlo Hornyak wrote:

Tom, is there other way in pg 7.4 than backporting PG_TRY? It seems a lot
of work.

IIRC PL/Python had a hack involving sigsetjmp (which was removed in
favor of the cleaner PG_TRY). You could try doing that.

Indeed, PG_TRY is just formalizing something that was done already in a
few places.

regards, tom lane

Laszlo,

Tom, is there other way in pg 7.4 than backporting PG_TRY? It seems a lot
of work.

I have the needed macros implemented for 7.4 in PL/Java. Look in
src/C/pljava.h.

The exception handling in versions prior to 8.0 is very rudimentary
though. There's (as you already discovered) no way to find the cause of
an error. The error is reported to the caller and discarded before the
longjmp occurs.

This *much* better in 8.0. Thank's Tom.

Regards,

Thomas Hallgren