2011/5/21 Alvaro Herrera <alvhe...@commandprompt.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 <alvhe...@commandprompt.com>
> The PostgreSQL Company - Command Prompt, Inc.
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
