Re: PL/pgSQL, RAISE and error context
| От | Pavel Stehule |
|---|---|
| Тема | Re: PL/pgSQL, RAISE and error context |
| Дата | |
| Msg-id | CAFj8pRBm12R0ggbodLWtwWmqGgEwKkH-0vh4e45On1uzjcjJsg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: PL/pgSQL, RAISE and error context (Marko Tiikkaja <marko@joh.to>) |
| Ответы |
Re: PL/pgSQL, RAISE and error context
|
| Список | pgsql-hackers |
2015-01-26 14:02 GMT+01:00 Marko Tiikkaja <marko@joh.to>:
On 1/26/15 1:44 PM, Pavel Stehule wrote:2015-01-26 13:39 GMT+01:00 Marko Tiikkaja <marko@joh.to>:On 1/26/15 1:14 PM, Pavel Stehule wrote:I afraid about some unexpected side effects of your proposal if somebody
mix languages - these side effects should not be critical
I have no idea what you're talking about. What kind of side effects?
what will be a error context if plpgsql calls a plperl function that raises
a exception
what will be a error context if plperl calls a plpgsql functions that
raises a exception
I fail to see the point. How would that be different from what happens today? Remember, PL/PgSQL only suppresses the *topmost* stack frame, and only when using RAISE from within a PL/PgSQL function.
I had to though little bit more - and I am thinking so we should to return back to start of this thread.
Current state:
1. RAISE in plpgsql doesn't show a context - what we want in RAISE NOTICE and we don't want in RAISE EXCEPTION
I am thinking, so solution
/* if we are doing RAISE, don't report its location */
if (estate->err_text == raise_skip_msg)
return;
/* 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.
2. Personally I prefer a little bit conceptual solution, that needs a libpq change because I wish some mode between terse and verbose mode - I would not to see context for NOTICEs, but I would to see context for errors. This request is generic - independent on used PL. @2 is my feature request and it is possible independent on @1.
3. your proposal plpgsql.suppress_simple_error_context fix the @2 partially - just I prefer a generic solution that will be available for all PL - exception processing is same for all PL, so filtering should be common too.
Regards
Pavel
.m
В списке pgsql-hackers по дате отправления: