From: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Peter Eisentraut" <peter_e(at)gmx(dot)net> |
Cc: | "Jan Wieck" <wieck(at)debis(dot)com>, "PostgreSQL Development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: When malloc returns zero ... |
Date: | 2000-05-02 01:42:22 |
Message-ID: | 000c01bfb3d7$a9425360$2801007e@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> -----Original Message-----
> From: pgsql-hackers-owner(at)hub(dot)org [mailto:pgsql-hackers-owner(at)hub(dot)org]On
> Behalf Of Tom Lane
>
> Peter Eisentraut <peter_e(at)gmx(dot)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
Regards.
Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Lockhart | 2000-05-02 01:59:37 | Re: [HACKERS] Request for 7.0 JDBC status |
Previous Message | Hiroshi Inoue | 2000-05-02 01:09:47 | RE: RE: [PATCHES] relation filename patch |