Re: bugfix: incomplete implementation of errhidecontext

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeevan Chalke <jeevan(dot)chalke(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: bugfix: incomplete implementation of errhidecontext
Date: 2015-07-07 12:32:39
Message-ID: CAFj8pRC9haWCoOq5ve9n4uDmCZptGoKV988wep_w4ngqFrPuQg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2015-07-07 14:13 GMT+02:00 Andres Freund <andres(at)anarazel(dot)de>:

> On 2015-07-03 06:20:14 +0200, Pavel Stehule wrote:
> > I would to use it for controlling (enabling, disabling) CONTEXT in RAISE
> > statement in plpgsql. I am thinking so one option for this purpose is
> > enough, and I would not to add other option to specify LOG, CLIENT.
>
> I don't think a plpgsql function should be able to suppress all
> context. From a security/debuggability POV that's a bad idea. The
> context messages are the only way right now to have any chance of
> tracing back what caused an error in a function because log_statements et
> al. will not show it.
>

It does it now. The context is not raised for exception raised by RAISE
statement from PL/pgSQL - and I would to fix it. But sometimes the context
is useless - for NOTICE level for example. I seen a strange workarounds -
RAISE NOTIFY followed by PERFORM 10/0 to get a context from PLpgSQL call.

Pavel

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2015-07-07 12:41:33 Re: FPW compression leaks information
Previous Message Andres Freund 2015-07-07 12:14:33 Re: Tab completion for CREATE SEQUENCE