Re: elog() proposal

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

Peter Eisentraut wrote:
> Tom Lane writes:
>
> > Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > > I think there should be separately named functions.
> >
> > You mean elog_debug(), elog_error(), ...? Seems pretty yucky.
>
> I would rather avoid the name "elog" altogether, for semantic and
> compatibility reasons. We could invent much nicer names, e.g.,
>
> LogDebug(int, const char*, ...)
> LogInfo(const char*, ...)
> AbortTransaction(const char*, ...)
> AbortSession(const char*, ...)
> AbortAllSessions(const char*, ...)

Wow, seems awfully complex to me. Doesn't our current system seem
clearer:

elog(DEBUG, ...)
elog(NOTICE, ...)
elog(ERROR, ...)

Our elog messages are long enough already.

> > > 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.

Can't we hack it to pull out only certain elogs()? Also, don't we have
to translate everything? I guess not.

> > I'm not sure that "type of error" really conveys much, or that we can
> > always tell what the cause of an error report is.
>
> What I mean with "type of error" is that there's a significant difference
> between user errors and server-side errors:
>
> 1. User errors should not necessarily go into the server log, unless
> command logging is enabled.
>
> 2. User errors will eventually carry additional information such as error
> codes. Server errors will just get one default error code.
>
> 3. Users should not necessarily be allowed to see the details of server
> errors at the client side, only some generic message.
>
> So if we made up two separate functions each for errors and notices, we
> could raise the awareness about this, even if initially the functionality
> would not differ much.

Seems my solution is smaller and backward compatible. I don't see the
value in tons of options.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-02-22 23:06:12 Re: TODO item inquiry/claim
Previous Message Peter Eisentraut 2002-02-22 22:34:32 Re: elog() proposal