Memory context in exception handler

I'm trying to use the PG_TRY/PG_CATCH exception handling:

bool
xml_is_document(xmltype *arg)
{
bool result;
xmlDocPtr doc;

PG_TRY();
{
doc = xml_parse((text *) arg, true, true);
result = true;
}
PG_CATCH();
{
ErrorData *errdata = CopyErrorData();
if (errdata->sqlerrcode == ERRCODE_INVALID_XML_DOCUMENT)
{
FlushErrorState();
result = false;
}
else
PG_RE_THROW();
}
PG_END_TRY();

if (doc)
xmlFreeDoc(doc);

return result;
}

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?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut <peter_e(at)gmx(dot)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

Tom Lane wrote:
> 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?

Yes, something like that would be good to have. At the moment, there
are not a lot of users of this mechanism in our code, so I'm not in a
hurry to change this (and I think that I want to rewrite the XML
parsing code to do without the exceptions dance).

--
Peter Eisentraut
http://developer.postgresql.org/~petere/