On Wed, Aug 21, 2013 at 10:47 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Merlin Moncure <mmoncure@gmail.com> writes:
>> On Wed, Aug 21, 2013 at 10:07 AM, Marko Tiikkaja <marko@joh.to> wrote:
>>> Why does \set VERBOSITY 'terse' not work for you?
>
>> Because it can't be controlled mid-function...that would suppress all
>> context of errors as well as messages and so it's useless. Also psql
>> directives for this purpose is a hack anyways -- what if I'm using a
>> non-psql client?
>
>> what I really want is:
>> SET LOCAL log_console_verbosity = 'x'
>
> There was a protocol design decision a long time ago that verbosity
> ought to be controlled on the client side. If we start suppressing
> fields server-side I think we're going to have problems. In particular,
> I'm going to throw the "what if I'm not using psql" argument right back
> at you: what's the reason for thinking that a different client/application
> would have the identical desires about what fields to see? It seems
> unlikely that a Java application, say, would want the server to be
> selective about what information it sends.
I didn't like that decision then and I don't like it now. Why should
the protocol mandate that error context always be sent? Why does this
have anything to do with the protocol at all? Just because we can't
imagine a case where a java application would not want context to be
sent in some or all contexts doesn't mean that operators should not
have control over it being emitted. What harm could providing an
option possibly cause?
> I'm entirely prepared to believe that psql's VERBOSITY behavior could
> use more options, though.
How would that be structured... \set VERBOSITY 'NOTICE:terse'?
merlin