Chapman Flack <chap@anastigmatix.net> writes:
> I decided, for a first point of reference, to wear the green eyeshade and
> write a pre-check that exactly implements the applicable rules. That gives
> a starting point for simplifications that are probably safe.
> For example, a bunch of lines at the end have to do with verifying the
> content inside of a processing-instruction, after finding where it ends.
> We could reasonably decide that, for the purpose of skipping it, knowing
> where it ends is enough, as libxml will parse it next and report any errors
> anyway.
Yeah, I did not like that code too much, particularly not all the magic
Unicode-code-point numbers. I removed that, made some other changes to
bring the patch more in line with PG coding style, and pushed it.
> That made me just want to try it now, and--surprise!--the messages from
> libxml are not the same. So maybe I would lean to keeping the green-eyeshade
> rules in the test, if you can stomach them, but I would understand taking
> them out.
I doubt anyone will care too much about whether error messages for bad
XML input are exactly like what they were before; and even if someone
does, I doubt that these extra tests would be enough to ensure that
the messages don't change. You're not really validating that the input
is something that libxml would accept, unless its processing of XML PIs
is far stupider than I would expect it to be.
regards, tom lane
