>> I agree with Peter at this point.
>> For example,even basic functions call elog() easily but we can't
>> catch the error and we(at least I) couldn't call basic functions
>> easily. In fact I suffered very much to avoid elog() call in order
>> to enable dropping tables whose base relation files has already
>> been removed
> The current model is also problematical in the case of procedural
> languages as well. Many times, when there is an error, both
> the backend and the PL handler needs to do cleanup. But it
> is very hard for the PL handler to 'capture' the exception in
> order to do the cleanup.
It would be fairly easy to extend the existing setjmp/longjmp support
to allow multiple layers of code to catch an elog(ERROR) on its way
out to the outer loop. That might be a better answer for things like
PL handlers than the current approach, which is basically "any cleanup
you need, you'd better be prepared to do as part of transaction abort
processing".
(BTW, I actually think that the current approach is more robust than
exception catchers for modules that are part of the standard system;
it forces on you the discipline of making sure that all recoverable
resources are tracked in data structures less transient than some
routine's local variables. But it's no help for add-on modules like
PL handlers, because they don't get called during transaction abort.
A partial answer might be to add a hook to allow add-ons to get called
during commit or abort cleanup?)
But if we did add support for multiple layers of longjmp catching,
the only thing that would really work in general would be for an
error catcher to do local cleanup and then pass the error on outwards
(possibly changing the error message). It would not be safe to catch
the error and then continue as if nothing had happened. There is too
much code that assumes that it doesn't have to leave things in a
particularly clean state when it elog()s, because transaction abort
will clean up after it. Fixing *that* would be a really major task,
and a perilous one.
regards, tom lane
