RE: When malloc returns zero ...

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

In response to

Responses

Browse pgsql-hackers by date

  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