Re: Memory context in exception handler

Peter Eisentraut <peter_e@gmx.net> writes:
> But this fails because CopyErrorData() complains by way of assertion 
> that we're still in ErrorContext.  A nearby comment suggests to switch 
> away to another context to preserve the data across FlushErrorState(), 
> but that doesn't seem necessary in this situation.  Are there other 
> reasons why this rule is so rigorously enforced?

I think it's a good error check because if you are trying to make a copy
of the current error data, doing so within the ErrorContext seems highly
unlikely to be safe.

As near as I can tell, you're using CopyErrorData not because you need
an actual copy but just because elog.c doesn't export any other API to
let you see the current sqlerrorcode.  Perhaps adding a function to
return the top stack entry's sqlerrorcode would be a better API change?
(I'm a bit uncomfortable with handing out direct access to the struct,
but getting a peek at sqlerrorcode or other scalar values seems safe
enough.)
        regards, tom lane