Re: elog() proposal

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: elog() proposal
Date: 2002-02-23 19:26:39
Message-ID: 200202231926.g1NJQdm28448@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Tom Lane wrote:
> >> I would love to make them macros, but I don't know a portable way to
> >> create macros with variable numbers of arguments. Do you feel like
> >> writing double parens?
> >>
> >> PGERROR((msg, ...))
>
> > Then we have to wonder what PGError is getting us that elog(ERROR)
> > isn't, except the ability to do internationalization based on the first
> > parameter.
>
> The reason that I'd like a layer of macros in there is that it would
> make it easier to handle acquisition of additional data about the
> error. In particular, I've long wanted to pass __FILE__ and __LINE__
> to the error handler so that the exact source code location of an
> error report could be available. It's not reasonable to expect people
> to write those in source code, but with a macro layer it'd be easy.
>
> If we are really going to make a source code overhaul of the elog calls,
> we ought not do it until we've thought about all the want-list items
> that have been expressed in the past --- error codes, source locations,
> cursor offsets, etc. I don't necessarily say we have to *do* all those
> at once, but I think it's folly to do a massive overhaul without being
> sure that we know what the future development path is going to be.
> Otherwise we'll still be looking to do another massive edit after we've
> gotten it right. Let's try to get it right beforehand, instead.

I guess that is the question. My changes are purely to control output
location simply from GUC and to clean up some loose ends. It is
backward compatible, at least at the source code level, which we already
discussed.

The question is whether we want a more major overhaul to return
function/line number information. In most cases, this would be turned
off, but in other cases we may want to enable it. I am not sure it is
worth the effort, and frankly, I don't even want to touch something like
that until just before beta when there are no outstanding patches and I
have the tree to myself, like when I run pgindent. It is something to
consider.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-02-23 19:36:55 Re: elog() proposal
Previous Message Tom Lane 2002-02-23 19:23:39 Re: recursive SQL functions