Re: elog() proposal

Bruce Momjian writes:

> First, I think ERROR/DEBUG/NOTICE/FATAL, etc are too generic and cause
> compile problems/warnings, especially with Perl.  I suggest renaming all
> elog levels to PG*, so it would be PGERROR and PGINFO.  We could also do
> E_* or E*.  I am interested in other opinions.

I think there should be separately named functions.  That would relieve us
from inserting many dummy return statements because it gives the compiler
a clue of what's going on, and we don't have to tag all strings as
translatable.

> Second, I propose adding two GUC variables that control how much elog()
> info is sent to the server and client logs.  I suggest
> 'server_message_min' with possible values DEBUG, LOG, NOTICE, ERROR,
> FATAL, CRASH; and 'client_message_min' with possible values INFO,
> NOTICE, ERROR, FATAL, CRASH.

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

Furthermore, in some instances you may want to send a different message to
client and server.  (E.g., a client doesn't necessarily have the right to
know the exact cause of a server crash.)

Also, user errors need to be able to carry information such as error
codes.

So, what we need to do is to figure out exactly which of the above
combinations are useful or desirable, what parameters they take, etc.  I
don't think just renaming a couple of things makes things better.  Also,
there needs to be a transition plan, or suddenly every user-compiled
module is broken.

-- 
Peter Eisentraut   peter_e@gmx.net