> No, I don't think so. The use-case for this sort of thing seems to me
> to be messages that are directed to the user or DBA, and don't want to
> be decorated with a lot of information about where they came from.
> That determination is usually pretty clear when you write the code.
For my case,
2011/10/15 Tom Lane :
> Pavel Stehule writes:
>> 2011/10/15 Robert Haas :
>>> On Sat, Oct 15, 2011 at 12:24 AM, Pavel Stehule
>>> wrote:
I have no problem with this. A context can be false for info and true
for other in default. Please, use a different identifier than
"context",
Pavel Stehule writes:
> 2011/10/15 Robert Haas :
>> On Sat, Oct 15, 2011 at 12:24 AM, Pavel Stehule
>> wrote:
>>> I have no problem with this. Â A context can be false for info and true
>>> for other in default. Please, use a different identifier than
>>> "context", that can be use for reading c
2011/10/15 Robert Haas :
> On Sat, Oct 15, 2011 at 12:24 AM, Pavel Stehule
> wrote:
>> I have no problem with this. A context can be false for info and true
>> for other in default. Please, use a different identifier than
>> "context", that can be use for reading context in future - maybe
>> "at
On Sat, Oct 15, 2011 at 12:24 AM, Pavel Stehule wrote:
> I have no problem with this. A context can be false for info and true
> for other in default. Please, use a different identifier than
> "context", that can be use for reading context in future - maybe
> "attach_context" or some similar.
er
Hello
2011/10/15 Josh Berkus :
>
>> Now that we have syntax for adding miscellaneous options to RAISE
>> statements, what I suggest we consider is a RAISE option that suppresses
>> all context lines for the message, perhaps
>>
>> RAISE NOTICE 'fee, fi, fo, fum' USING context = false;
>
> Yeah, tha
Florian Pflug writes:
> On Oct14, 2011, at 23:51 , Tom Lane wrote:
>> It seems to me that a client-side facility would be unlikely to do the
>> right things, because it has not got enough information to know which
>> messages came from plpgsql RAISE commands. Moreover, it's not apparent
>> that a
On Oct14, 2011, at 23:51 , Tom Lane wrote:
> Josh Berkus writes:
>>> I meant verbosity, not error level. This quick test shows what I meant
>>> -- but it doesn't work; the server log is altered as I expected (and does
>>> not
>>> include the context lines), but not plpgsql's:
>
>> Yeah, what we
On Oct14, 2011, at 20:00 , Josh Berkus wrote:
>>> We do transmit the individual parts of a NOTICE separately, so I'd say
>>> suppressing some of them is the client's job. So, instead of a GUC I'd say
>>> we'd need a psql setting ERROR_VERBOSITY.
>>
>> Well, we do have a psql setting as well (\set
> Now that we have syntax for adding miscellaneous options to RAISE
> statements, what I suggest we consider is a RAISE option that suppresses
> all context lines for the message, perhaps
>
> RAISE NOTICE 'fee, fi, fo, fum' USING context = false;
Yeah, that would do it. Pavel? ;-)
--
Josh Be
Josh Berkus writes:
> In any case, this doesn't address the inconsistency of supressing
> CONTEXT for the first level of the call stack with RAISE INFO but not
> for the others. (RAISE EXCEPTION shows CONTEXT for all levels of the
> call stack).
Oh? I don't see that. AFAICT the behavior is not
Josh Berkus writes:
>> I meant verbosity, not error level. This quick test shows what I meant
>> -- but it doesn't work; the server log is altered as I expected (and does not
>> include the context lines), but not plpgsql's:
> Yeah, what we'd need is a client_error_verbosity setting.
It seems t
>> We do transmit the individual parts of a NOTICE separately, so I'd say
>> suppressing some of them is the client's job. So, instead of a GUC I'd say
>> we'd need a psql setting ERROR_VERBOSITY.
>
> Well, we do have a psql setting as well (\set VERBOSITY). But is Josh
> using psql?
Not in thi
Excerpts from Florian Pflug's message of vie oct 14 14:41:11 -0300 2011:
>
> On Oct14, 2011, at 19:27 , Josh Berkus wrote:
> >> I meant verbosity, not error level. This quick test shows what I meant
> >> -- but it doesn't work; the server log is altered as I expected (and does
> >> not
> >> inc
On Oct14, 2011, at 19:27 , Josh Berkus wrote:
>> I meant verbosity, not error level. This quick test shows what I meant
>> -- but it doesn't work; the server log is altered as I expected (and does not
>> include the context lines), but not plpgsql's:
>
> Yeah, what we'd need is a client_error_ver
> I meant verbosity, not error level. This quick test shows what I meant
> -- but it doesn't work; the server log is altered as I expected (and does not
> include the context lines), but not plpgsql's:
Yeah, what we'd need is a client_error_verbosity setting.
--
Josh Berkus
PostgreSQL Experts
Excerpts from Josh Berkus's message of vie oct 14 14:16:43 -0300 2011:
>
> > Maybe set the verbosity to a lower level in the function? I dunno if
> > plpgsql lets you do that though. We have a GUC that controls the server
> > log verbosity, and psql can do it too; but plpgsql is sort of in
> >
> Maybe set the verbosity to a lower level in the function? I dunno if
> plpgsql lets you do that though. We have a GUC that controls the server
> log verbosity, and psql can do it too; but plpgsql is sort of in
> between.
The problem is that there is no level of verbosity which will supress
th
Excerpts from Josh Berkus's message of vie oct 14 13:52:32 -0300 2011:
> All,
>
> I'm noticing some inconsistent and (I believe) undesirable behavior on
> RAISE INFO.
>
> If you call a function, and it posts progress reports using RAISE INFO,
> then you get the INFO statements plain back to the
19 matches
Mail list logo
