From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Marko Tiikkaja <marko(at)joh(dot)to>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PL/pgSQL, RAISE and error context |
Date: | 2013-08-21 15:47:19 |
Message-ID: | 6656.1377100039@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
> On Wed, Aug 21, 2013 at 10:07 AM, Marko Tiikkaja <marko(at)joh(dot)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'm entirely prepared to believe that psql's VERBOSITY behavior could
use more options, though.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2013-08-21 16:28:32 | Re: Back-patch change in hashed DISTINCT estimation? |
Previous Message | Marko Tiikkaja | 2013-08-21 15:47:02 | Re: PL/pgSQL, RAISE and error context |