2015-07-07 15:56 GMT+02:00 Merlin Moncure <mmonc...@gmail.com>: > 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 >
what is RAISE EXCEPTION - first or second case? > > 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). I can't throw > the verbose switch to terse because if the error happens to be > 'Division by Zero', or some other difficult to trace problem then I'm > sunk. I believe the protocol decision to 'always send context' needs > to be revisited; if your server-side codebase is large and heavily > nested it makes logging an expensive operation even if the client > strips off the log. > > plpgsql.min_context seems like the ideal solution to this problem; it > can be managed on the server or the client and does not require new > syntax. If we require syntax to slip and and out of debugging type > operations the solution has missed the mark IMNSHO. > > merlin >
