I am sending a next variant of filtering context patch.
postgres=# do $$ begin raise notice 'kuku'; end $$; NOTICE: kuku DO Time: 2.441 ms postgres=# do $$ begin raise exception 'kuku'; end $$; ERROR: kuku CONTEXT: PL/pgSQL function inline_code_block line 1 at RAISE Time: 0.648 ms postgres=# \set SHOW_CONTEXT always postgres=# do $$ begin raise notice 'kuku'; end $$; NOTICE: kuku CONTEXT: PL/pgSQL function inline_code_block line 1 at RAISE DO Time: 0.702 ms
It is a variant, when I try to filter CONTEXT in libpq. There is little bit less granularity on libpq side than server side, but still it is enough - always, error, none.
This patch is without documentation, but basic regress tests works.
On Tue, Jul 21, 2015 at 2:53 AM, Heikki Linnakangas <hlinnaka@iki.fi> wrote: > On 07/21/2015 10:38 AM, Pavel Stehule wrote: >> >> where we are with this patch? Can I do some for it? > > > I still feel this approach is misguided, and we should be tweaking psql > and/or libpq instead. I don't feel strongly though, and if some other > committer wants to pick this up in its current form, I won't object. So this > patch has reached an impasse, and if no-one else wants to pick this up, I'm > going to mark this as "Returned with Feedback" and move on.
That's unfortunate. Maybe I'm missing something:
What does a client side implementation offer that a server side implementation does not offer?
I have not any problem to change the filtering to client side. Primary question is fix of PLpgSQL RAISE statement issue - The context field filtering is a necessary follow-up and trivial in both cases.
