Alvaro Herrera <alvhe...@commandprompt.com> writes:
> 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?
The argument is nonsense anyway, because it's based on an incorrect
implementation. exec_stmt_block has no business calling the error
context stack --- that was already done in errfinish. Worse, by the time
you get control back from the longjmp, you probably have popped off some
of the stack variables that those links would need to use. If that code
didn't dump core in testing, it's likely only because it wasn't tested
very much.
A bigger issue is that it seems like this is an abuse of GET
DIAGNOSTICS. The existing options of that statement report on the
results of the immediately preceding command. If we add options that
report on the last error, then we will have a situation where some of
the options have different "lifespan" than others. That seems pretty
klugy and confusing to me.
I'm not real sure what to do instead. If we were actually trying to
follow precedent here, what we'd be looking to do is add more
auto-initialized variables like SQLERRM inside recovery blocks.
That would again have the issue of wasting cycles in code that never
actually looked at the variables. (But I wonder if we couldn't tweak
plpgsql so that we could determine at compile time which variables have
references and which don't, so that we'd not bother filling in variables
that weren't used. Or somehow arrange to only do the work when the
variable's value is accessed.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
