Re: PL/pgSQL, RAISE and error context

2015-07-07 15:56 GMT+02:00 Merlin Moncure <mmoncure(at)gmail(dot)com>:

> On Tue, Jul 7, 2015 at 8:13 AM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
> wrote:
> > On 01/26/2015 05:14 PM, Tom Lane wrote:
> >>
> >> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> >>>
> >>> 2015-01-26 14:02 GMT+01:00 Marko Tiikkaja <marko(at)joh(dot)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
>