Re: elog() proposal - Mailing list pgsql-hackers

From Tom Lane
Subject Re: elog() proposal
Date
Msg-id 25102.1014484574@sss.pgh.pa.us
Whole thread Raw
In response to Re: elog() proposal  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: elog() proposal  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: elog() proposal
Next
From: Tom Lane
Date:
Subject: Re: Patches split from 7.3 queue