On 07/07/2015 04:56 PM, Merlin Moncure wrote:
On Tue, Jul 7, 2015 at 8:13 AM, Heikki Linnakangas <hlinn...@iki.fi> wrote:
On 01/26/2015 05:14 PM, Tom Lane wrote:
Pavel Stehule <pavel.steh...@gmail.com> writes:
2015-01-26 14:02 GMT+01:00 Marko Tiikkaja <ma...@joh.to>:
I am thinking, so solution
/* if we are doing RAISE, don't report its location */
if (estate->err_text == raise_skip_msg)
return;
is too simple, and this part should be fixed. This change can be done by
on
plpgsql or libpq side. This is bug, and it should be fixed.
Doing this in libpq is utterly insane. It has not got sufficient context
to do anything intelligent. The fact that it's not intelligent is exposed
by the regression test changes that the proposed patch causes, most of
which do not look like improvements.
How can the server know if the client wants to display context information?
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.
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.
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.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
