Re: Updating psql for features of new FE/BE protocol - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Updating psql for features of new FE/BE protocol
Date
Msg-id 200306260054.h5Q0smI18238@candle.pha.pa.us
Whole thread Raw
In response to Re: Updating psql for features of new FE/BE protocol  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Updating psql for features of new FE/BE protocol  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Kevin Brown <kevin@sysexperts.com> writes:
> > Tom Lane wrote:
> >> Also, I would like to provide the same set of options w.r.t. messages
> >> logged in the server log.  Here there is an additional frammish that
> >> could be imagined, ie, more detail for more-serious errors.  Any
> >> opinions about what it should look like?
> 
> > Not sure exactly what you're asking for here.  If you're asking what
> > additional detail should be included for more serious errors,
> 
> No, I was asking whether anyone thought such behavior should be
> user-controllable, and if so exactly how the controlling GUC variables
> should be defined.
> 
> One way I could imagine doing it is to split log_min_messages into
> three variables, along the lines of "minimum message level to produce
> a TERSE report", "minimum message level to produce a DEFAULT report",
> and "minimum message level to produce a VERBOSE report".  This seems
> a bit inelegant though.  Better ideas anyone?

I doubt someone would want to control terse/default/verbose at various
levels --- I assume they would just want all their messages to be
terse/default/ or verbose.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: The Hermit Hacker
Date:
Subject: Re: Two weeks to feature freeze
Next
From: John DeSoi
Date:
Subject: row description for domain in 7.4