Re: alternative to PG_CATCH

Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> The fundamental problem, as I see it, is that the macro expansion needs
> to produce the "finally" code twice: Once in the else (error) branch of
> the setjmp, and once in the non-error code path, either after the
> if-setjmp, or in the try block. But to be able to do that, we need to
> capture the block as a macro argument.

I don't especially like the MACRO({...}) proposal, because it looks way
too much like gcc's special syntax for "statement expressions". If we
have to go this way, I'd rather see if MACRO((...)) can be made to work.
But I question your assumption that we have to have two physical copies
of the "finally" code. There's nothing wrong with implementing this
sort of infrastructure with some goto's, or whatever else we have to
have to make it work. Also, it'd look more natural as an extension
to the existing PG_TRY infrastructure if the source code were like

PG_TRY();
{
...
}
PG_FINALLY();
{
...
}
PG_END_TRY();

So even if Kyotaro-san's initial sketch isn't right in detail,
I think he has the right idea about where we want to go.

regards, tom lane