> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
>
> >> 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.
Hmm,for the query SELECT .. FROM .. WHERE int2key = 1;
we coudn't try to convert 1 -> 1::int2 because the conversion may
cause elog(ERROR). Isn't it too restrictive ?
Comments ?
Hiroshi Inoue
Inoue@tpf.co.jp