2015-01-26 14:02 GMT+01:00 Marko Tiikkaja <ma...@joh.to>:
> On 1/26/15 1:44 PM, Pavel Stehule wrote:
>
>> 2015-01-26 13:39 GMT+01:00 Marko Tiikkaja <ma...@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;
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
>
