Re: Call stacks and RAISE INFO

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Florian Pflug <fgp(at)phlo(dot)org>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Call stacks and RAISE INFO
Date: 2011-10-14 23:08:16
Message-ID: 27722.1318633696@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Florian Pflug <fgp(at)phlo(dot)org> 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 one-size-fits-all approach is suitable anyhow: it may be that
>> some RAISEs don't need context traceback while others could use it.

> Hm, I think you'd usually want to adjust the verbosity of log messages
> when you *run* code, not when you *write* it. That's the raison d'etre
> for having logging infrastructure and verbosity settings, after all.

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.

Moreover, if we don't attach the specification to particular RAISE
commands, it's going to be "all or nothing", which is most definitely
not the right thing.

Having said that, if we allow "USING context = boolean_expression",
it'd be possible for the plpgsql coder to make the behavior run-time
adjustable if he wanted.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2011-10-15 00:26:38 Re: about EDITOR_LINENUMBER_SWITCH
Previous Message Heikki Linnakangas 2011-10-14 22:46:26 Re: Range Types - typo + NULL string constructor