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
enough.)
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
