Re: elog() proposal

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: elog() proposal
Дата
Msg-id 25102.1014484574@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: elog() proposal  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: elog() proposal  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: elog() proposal
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Patches split from 7.3 queue