On Wed, Jul 2, 2014 at 2:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Greg Stark <stark@mit.edu> writes:
>> I think log_error_verbosity is a strange variable. It's useless for
>> expected user-facing errors but essential for unexpected errors that
>> indicate bugs in the code -- and you can only have it on for
>> everything or off for everything.
>
>> I'm finding I usually want it set to 'verbose' for anything that
>> PANICs or is generated by an elog() but it's just noise for anything
>> generated by an ereport() and is ERROR or below.
>
>> The minimum suggested change would to make it implicitly true for
>> PANIC and any unexpected elog()s and leave the GUC for enabling it in
>> the other cases.
>
> Hm. I'm okay with the PANIC idea, I think, but the other not so much.
> That would change the rule of thumb that "elog is for non user facing
> errors" into something more than just permission to be lazy. In
> particular, elog currently is (and is documented to be) equivalent to
> an ereport call with suitable parameters. I'm not terribly happy about
> losing that equivalence, because I don't think that people have been
> especially careful about which to use. contrib is still full of
> user-facing conditions reported via elog, for instance, and I expect
> that third-party code is worse.
>
> [ thinks for a bit... ] A slightly cleaner approach is to nominate
> a specified set of SQLSTATEs, certainly including XX000 and perhaps
> some others, as being ones that force verbose reporting. That would
> have the same practical effect as far as elogs go, but wouldn't break
> the nominal functional equivalence.
That's a really nifty idea. If you recall, I griped a while back
about the fact that there was no good setting for the psql VERBOSITY
switch. In particular, it would be nice to have context for errors
but not for notices.
Marko had proposed a new verbosity level (see commentary leading to
unfinished patch here;
http://postgresql.1045698.n5.nabble.com/PL-pgSQL-RAISE-and-error-context-td5768176.html).
Not trying to hijack your thread, just wondering out load if a
SQLSTATE driven verbosity decision, if you were to do that,
could/should also be hooked to client console logging and/or psql.
merlin
