Re: When malloc returns zero ...
От | Mark Hollomon |
---|---|
Тема | Re: When malloc returns zero ... |
Дата | |
Msg-id | 390ECBA9.188C378E@americasm01.nt.com обсуждение исходный текст |
Ответ на | RE: When malloc returns zero ... ("Hiroshi Inoue" <Inoue@tpf.co.jp>) |
Ответы |
Re: When malloc returns zero ...
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: