| 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
| 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 |