Re: elog() proposal

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: elog() proposal
Date: 2002-02-22 23:38:50
Message-ID: 21509.1014421130@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-02-23 00:20:11 Re: elog() proposal
Previous Message Bruce Momjian 2002-02-22 23:34:53 Re: [Fwd: [PATCHES] Libpq support for precision and scale]