On Wednesday, July 24, 2013, Tom Lane wrote:
Stephen Frost <sfrost@snowman.net> writes:
> That said, I'll work on making this more independent of the error handling
> and see if it can be made to use an independent memory context and try to
> tighten it up to ensure it isn't called in an error case. Future callers
> may try to.
I'm not following your reasoning here. This *has* to be called in an
error case, before you're outside the error processing context.
Otherwise there would be no data available to be printed.
It has to be called after the context callbacks have been set up by the levels above it on the stack (eg: SPI calls), but that's not the same as being called from an actual exception. The idea here is to simply execute the callbacks for each level above it on the stack and collect the strings they create with errcontext().
In short: FlushErrorState, by definition, destroys the information that
GetErrorContextStack looks at. So in the current implementation,
GetErrorContextStack is burning its bridges behind it. That's at the
very least a surprising behavior. I am betting that it will have
unpleasant consequences for any sort of nested-error scenario.
Unfortunately, I don't have the code in front of me at the moment, but I was pretty sure FlushErrorState cleans up the intermediate information set up during an individual error call and doesn't completely clear the stack info (tho I can't think of what, if anything, does..) or multiple "raise notices" wouldn't each contain the stack info in their output..
I'll certainly look through this again and dream up some additional test cases for it, in the morning.
Thanks,
Stephen