Peter Eisentraut <peter_e@gmx.net> writes:
> I think there should be separately named functions.
You mean elog_debug(), elog_error(), ...? Seems pretty yucky.
> That would relieve us
> from inserting many dummy return statements because it gives the compiler
> a clue of what's going on,
Only in gcc; if we remove the return statements then we still will get
warnings in compilers that don't recognize gcc's attributes. I think
this is a *bad* idea.
> and we don't have to tag all strings as translatable.
Huh? How does having multiple functions instead of one help there?
> I think there are a lot more possible combinations of behaviour we need to
> take care of and we might as well get rid of this linear level system
> altogether. Some categorizations:
> * How to proceed: return to caller, abort transaction, abort session,
> abort all sessions
> * Where to send output: client, server log, both
> * Type of error: code bug (assert), server failure, user/client error
Dubious. "How to proceed" clearly must be encoded in the elog call,
since generally the code surrounding the call point is not prepared to
cope with alternative behaviors. However, "where to send output" ought
to be configurable, as I have argued elsewhere. 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.
> Furthermore, in some instances you may want to send a different message to
> client and server.
Hmm, maybe, but I sure don't want to be passing two strings in every
elog call. There might be a *small* number of cases where the above is
true, and we could use a specialized variant of elog for them.
> Also, user errors need to be able to carry information such as error
> codes.
Agreed, but I suggested a grand revision of elog calls a year ago, and
no one had the energy to take it on. I think we shall have to resign
ourselves to fixing one issue at a time... unless you want to go back
to the grand plan?
> there needs to be a transition plan, or suddenly every user-compiled
> module is broken.
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.)
regards, tom lane