Peter Eisentraut <[EMAIL PROTECTED]> 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

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Reply via email to