Re: Error-safe user functions

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Tom, I just want to extend huge thanks to you for working on this
> infrastructure.

Thanks. I agree it's an important bit of work.

I'm going to step back from this for now and get on with other work,
but before that I thought there was one more input function I should
look at: xml_in, because xml.c is such a hairy can of worms. It
turns out to be not too bad, given our design principle that only
"bad input" errors should be reported softly. xml_parse() now has
two different ways of reporting errors depending on whether they're
hard or soft, but it didn't take an undue amount of refactoring to
make that work.

While fixing that, my attention was drawn to wellformed_xml(),
whose error handling is unbelievably horrid: it traps any longjmp
whatsoever (query cancel, for instance) and reports it as ill-formed XML.
0002 attached makes use of this new code to get rid of the need for any
PG_TRY there at all; instead, soft errors result in a "false" return
but hard errors are allowed to propagate. xml_is_document was much more
careful, but we can change it the same way to save code and cycles.

regards, tom lane