2015-07-08 23:46 GMT+02:00 Merlin Moncure <mmonc...@gmail.com>: > On Wed, Jul 8, 2015 at 4:39 PM, Pavel Stehule <pavel.steh...@gmail.com> > wrote: > > 2015-07-08 8:35 GMT+02:00 Pavel Stehule <pavel.steh...@gmail.com>: > >> > >> > >> > >> 2015-07-07 18:15 GMT+02:00 Merlin Moncure <mmonc...@gmail.com>: > >>> > >>> On Tue, Jul 7, 2015 at 9:04 AM, Pavel Stehule <pavel.steh...@gmail.com > > > >>> wrote: > >>> >> It doesn't have to if the behavior is guarded with a GUC. I just > >>> >> don't understand what all the fuss is about. The default behavior > of > >>> >> logging that is well established by other languages (for example > java) > >>> >> that manage error stack for you should be to: > >>> >> > >>> >> *) Give stack trace when an uncaught exception is thrown > >>> >> *) Do not give stack trace in all other logging cases unless asked > for > >>> > > >>> > what is RAISE EXCEPTION - first or second case? > >>> > >>> First: RAISE (unless caught) is no different than any other kind of > >>> error. > >>> > >>> On Tue, Jul 7, 2015 at 9:42 AM, Heikki Linnakangas <hlinn...@iki.fi> > >>> wrote: > >>> > On 07/07/2015 04:56 PM, Merlin Moncure wrote: > >>> >> It doesn't have to if the behavior is guarded with a GUC. I just > >>> >> don't understand what all the fuss is about. The default behavior > of > >>> >> logging that is well established by other languages (for example > java) > >>> >> that manage error stack for you should be to: > >>> >> > >>> >> *) Give stack trace when an uncaught exception is thrown > >>> >> *) Do not give stack trace in all other logging cases unless asked > for > >>> > > >>> > Java's exception handling is so different from PostgreSQL's errors > that > >>> > I > >>> > don't think there's much to be learned from that. But I'll bite: > >>> > > >>> > First of all, Java's exceptions always contain a stack trace. It's up > >>> > to you > >>> > when you catch an exception to decide whether to print it or not. > "try > >>> > { ... > >>> > } catch (Exception e) { e.printStackTrace() }" is fairly common, > >>> > actually. > >>> > There is nothing like a NOTICE in Java, i.e. an exception that's > thrown > >>> > but > >>> > doesn't affect the control flow. The best I can think of is > >>> > System.out.println(), which of course has no stack trace attached to > >>> > it. > >>> > >>> exactly. > >>> > >>> > Perhaps you're arguing that NOTICE is more like printing to stderr, > and > >>> > should never contain any context information. I don't think that > would > >>> > be an > >>> > improvement. It's very handy to have the context information > available > >>> > if > >>> > don't know where a NOTICE is coming from, even if in most cases > you're > >>> > not > >>> > interested in it. > >>> > >>> That's exactly what I'm arguing. NOTICE (and WARNING) are for > >>> printing out information to client side logging; it's really the only > >>> tool we have for that purpose and it fits that role perfectly. Of > >>> course, you may want to have NOTICE print context, especially when > >>> debugging, but some control over that would be nice and in most cases > >>> it's really not necessary. I really don't understand the objection to > >>> offering control over that behavior although I certainly understand > >>> wanting to keep the default behavior as it currently is. > >>> > >>> > This is really quite different from a programming language's > exception > >>> > handling. First, there's a server, which produces the errors, and a > >>> > separate > >>> > client, which displays them. You cannot catch an exception in the > >>> > client. > >>> > > >>> > BTW, let me throw in one use case to consider. We've been talking > about > >>> > psql, and what to print, but imagine a more sophisticated client like > >>> > pgAdmin. It's not limited to either printing the context or not. It > >>> > could > >>> > e.g. hide the context information of all messages when they occur, > but > >>> > if > >>> > you double-click on it, it's expanded to show all the context, > location > >>> > and > >>> > all. You can't do that if the server doesn't send the context > >>> > information in > >>> > the first place. > >>> > > >>> >> I would be happy to show you the psql redirected output logs from my > >>> >> nightly server processes that spew into the megabytes because of > >>> >> logging various high level steps (did this, did that). > >>> > > >>> > Oh, I believe you. I understand what the problem is, we're only > talking > >>> > about how best to address it. > >>> > >>> Yeah. For posterity, a psql based solution would work fine for me, > >>> but a server side solution has a lot of advantages (less protocol > >>> chatter, more configurability, keeping libpq/psql light). > >> > >> > >> After some work on reduced version of "plpgsql.min_context" patch I am > >> inclining to think so ideal solution needs more steps - because this > issue > >> has more than one dimension. > >> > >> There are two independent issues: > >> > >> 1. old plpgsql workaround that reduced the unwanted call stack info for > >> RAISE NOTICE. Negative side effect of this workaround is missing context > >> info about the RAISE command that raises the exception. We know a > function, > >> but we don't know a line of related RAISE statement. The important is > fact, > >> so NOTICE doesn't bubble to up. So this workaround was relative > successful > >> without to implement some filtering on client or log side. > > > > > > I found a other issue of this workaround - it doesn't work well for > nested > > SQL statement call, when inner statement invoke RAISE NOTICE. In this > case a > > context is showed too. > > > > postgres=# insert into xx values(60); > > NOTICE: <<<<<>>>>>> > > NOTICE: trigger_func(before_ins_stmt) called: action = INSERT, when = > > BEFORE, level = STATEMENT > > CONTEXT: SQL statement "INSERT INTO boo VALUES(30)" > > PL/pgSQL function hh() line 1 at SQL statement > > > > So filtering context for selected environment is not good idea. The > result > > is fragmented context, where is not clear, what is missing. > > not quite following you. Is this a problem with your proposed patch, > or a reason why your patch is the 'right' implementation? >
My patch fixes it. The current design is not consistent. Pavel > > merlin >