Re: PL/pgSQL, RAISE and error context - Mailing list pgsql-hackers

On Tue, Jul 7, 2015 at 9:04 AM, Pavel Stehule <pavel.stehule@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 <hlinnaka@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).

merlin