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
|
Список | 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 по дате отправления: