Re: Call stacks and RAISE INFO
От | Florian Pflug |
---|---|
Тема | Re: Call stacks and RAISE INFO |
Дата | |
Msg-id | ADC4E134-0C31-41DB-85E0-EC50BC3344A0@phlo.org обсуждение исходный текст |
Ответ на | Re: Call stacks and RAISE INFO (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Call stacks and RAISE INFO
|
Список | pgsql-hackers |
On Oct14, 2011, at 23:51 , Tom Lane wrote: > Josh Berkus <josh@agliodbs.com> 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 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. When I'm running a function from psql interactively, I probably want to suppress CONTEXT and maybe STATEMENT lines for NOTICEs - presumably the message itself tells me everything I need to know. When I'm running the same function in a setting where there messages go to a log file, I probably want to include as much context information as necessary in order to be able to debug possible problems post-mortem. Having said that, having the option to not emit CONTEXT lines in the first place wouldn't hurt of course. best regards, Florian Pflug
В списке pgsql-hackers по дате отправления: