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).
>
I prefer a server side solution too. With it I can have (as plpgsql
developer) bigger control of expected output.
Client can change this behave on global (min_context) or on language level
(plpgsql.min_context). If somebody afraid about security, we can to enforce
rule so min_context <= error always.
The possibility to enable or disable context per any RAISE statement is
nice to have, but it is not fundamental.
Other variant is a implementation of min_context on client side - but then
we cannot to ensure current behave and fix plpgsql raise exception issue
together.
Pavel
>
> merlin
>
