Re: proposal: enhanced get diagnostics statement

2011/5/21 Alvaro Herrera <alvherre(at)commandprompt(dot)com>:
> Excerpts from Pavel Stehule's message of sáb may 21 16:05:01 -0400 2011:
>
>> A implementation of ERROR_CONTEXT is not without impact on
>> performance, because context should be collected when exception is
>> caught. One solution is removing a ERROR_CONTEXT from proposal. Second
>> solution can be a design of enhanced syntax for exception trap like
>> (it means - collect CONTEXT when exception is handled)
>
> I don't understand why we should worry about this.  I mean, if you don't
> catch the error, you have to form errcontext anyway.  Why is it a
> problem to generate it when the exception is caught?

Generating context means a calling a few functions with some string
operations - because in this moment is limited functionality, there
isn't too much operations - but it can be changed - PL/PSM dumps all
local variables, ...

somebody uses a exception trapping like mechanism for ignoring errors

FOR r IN SELECT ..
LOOP
BEGIN
INSERT INTO ...
EXCEPTION WHEN OTHERS THEN
/* do nothing */
END;
END LOOP;

or some body can do

BEGIN
...
EXCEPTION WHEN OTHERS THEN
RAISE WARNING ' .....';
RAISE;
END;

In last case the context can wanted - so it cannot be hard problem.
But first case is problem and we has not different way how to do it.

Maybe we can use a simple optimization

when function doesn't contain a GET DIAGNOSTICS statement with
ERROR_CONTEXT field, then we can not collect a context. Only when
function has GET DIAGNOSTICS with ERROR_CONTEXT we will take context
info. This strategy ensure, so there will not be negative performance
effect on current applications.

Pavel

>
> --
> Álvaro Herrera <alvherre(at)commandprompt(dot)com>
> The PostgreSQL Company - Command Prompt, Inc.
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>