Re: elog() patch

> > > I also like LOG, since I don't like the current NOTICES in the log.
> > 
> > Good, that was one of my goals.
> > 
> > > Imho INFO and WARNING would be nothing for the log per default.
> > > LOG would be things that are only of concern to the DBA.
> > > My preferred client level would prbbly be WARNING (no INFO).
> > 
> > Well, that is interesting.  Currently we would send WARNING/NOTICE to
> > the logs because it is an exceptional condition, though not as serious
> > as error.
> 
> Well, string truncation is imho not for the log, might interest the app
> programmer but probably not the dba ? And if your point was to get rid 
> of the notices in the log (as is mine) you would have to not log Warning, 
> no ?

OK, now things could get complicated.  If we don't want to see
NOTICE/WARNING in the log, you could say you don't want to see ERROR in
the log, particularly syntax errors.  Where do we go from here?  You
could set your server_min_messages to FATAL, but then you don't see LOG
messages about server startup.

I have considered allowing individual message types to be specified,
particularly for the server logs, but the user API for that,
particilarly as SET from psql, becomes very complicated.

Maybe I have the ordering wrong for server_min_messages.  Perhaps it
should be:
DEBUG5-1, INFO, NOTICE/WARNING, ERROR, LOG, FATAL, PANIC

Nothing prevents us from doing that.  Well, anyway, not sure how much I
like it but I throw it out as an idea.

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