Re: elog() proposal
От | Tom Lane |
---|---|
Тема | Re: elog() proposal |
Дата | |
Msg-id | 21509.1014421130@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: elog() proposal (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: elog() proposal
|
Список | pgsql-hackers |
Peter Eisentraut <peter_e@gmx.net> writes: >> You mean elog_debug(), elog_error(), ...? Seems pretty yucky. > I would rather avoid the name "elog" altogether, for semantic and > compatibility reasons. Okay; it was never a particularly nice name anyway. But --- > We could invent much nicer names, e.g., > LogDebug(int, const char*, ...) > LogInfo(const char*, ...) > AbortTransaction(const char*, ...) > AbortSession(const char*, ...) > AbortAllSessions(const char*, ...) Well, (a) AbortTransaction is taken; (b) I would like to see these names kept as short as possible, to leave more room on the line for the error message text. We could do something like this involving abbreviations, I suppose, but the existing and proposed mnemonics (LOG, INFO, ..., CRASH) seem perfectly usable to me. >>> and we don't have to tag all strings as translatable. >> >> Huh? How does having multiple functions instead of one help there? > The string extractor can only go by function name, not arguments. Oh, now I get the point: you want to not pick up debug-level messages for translation at all. That makes sense. Okay, how about we take the names Bruce was proposing and make them function names: PGLog(msg, ...)PGError(msg, ...)PGCrash(msg, ...) regards, tom lane
В списке pgsql-hackers по дате отправления: