Re: elog() proposal

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(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 17:16:14
Message-ID: 25102.1014484574@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-02-23 17:23:20 Re: Patches split from 7.3 queue
Previous Message Tom Lane 2002-02-23 17:04:38 Re: elog() proposal