Re: elog() proposal

Tom Lane writes:

> Peter Eisentraut <peter_e@gmx.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*, ...)

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

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

> Also agreed.  Probably the new function has to be called something else
> than elog in any case, so that we can have a compatibility layer to
> accept old elog calls.  (That'd avoid requiring a "big bang" patch, too,
> which'd surely ease making the changes.)

Exactly.

-- 
Peter Eisentraut   peter_e@gmx.net