Hiroshi Inoue wrote:
>
> > -----Original Message-----
> > From: pgsql-hackers-owner@hub.org [mailto:pgsql-hackers-owner@hub.org]On
> > Behalf Of Tom Lane
> >
> > Peter Eisentraut <peter_e@gmx.net> writes:
> > > A while ago I went on record saying that elog is a pain for the
> > user. Now
> > > I'd like to add it's a pain for developers, too. Having what's
> > essentially
> > > an exception model without a way to catch exceptions is disastrous.
> >
> > I think that's a bit overstated ... we've gotten along fine with this
> > model so far, and I haven't seen any compelling reason to change it.
>
> 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. Witness the ingenious lengths Jan had
to go to, to do it in pltcl. I've tried to do the same in plperl
but am not convinved that it is correct. And even if I get it
correct, maintainability suffers greatly.
--
Mark Hollomon
mhh@nortelnetworks.com
ESN 451-9008 (302)454-9008
