On Jul26, 2011, at 17:07 , Tom Lane wrote: > Florian Pflug <f...@phlo.org> writes: >> What about the suggested upgrade of the elog(ERROR) in xml_errorHandler >> to elog(FATAL)? Shall I do that too, or leave it for now? > > No objection here --- I had considered writing it that way myself. > I refrained for fear of making a bad situation even worse, but if > other people think FATAL would be the safer way, fine.
Patch attached. pg_xml_init() now checks the error context after setting it, and ereport(ERROR)s if the check fails. I've made it so that the errhint() which suggest that compiling against libxml <= 2.7.3 but running against > 2.7.3 might be the reason is only emitted if we actually compiled against an older version. This is meant to avoid confusion should there ever be another reason for that check to fail. I've also changed the elog(ERROR) to elog(FATAL) in xml_errorHandler(). I've pondered whether to add a check to configure which verifies that the headers match the libxml version exactly at compile time. In the end, I didn't do that, for two reasons. First, there isn't anything wrong with using older headers together with a newer libxml, so long as both versions are either <= 2.7.3 or > 2.7.3. And second, with such a check in place, the only way to exercise libxml's promised ABI compatibility is to upgrade the libxml 2package after compiling postgres. That, however, is unlikely to happen except on production servers, and so by adding the check we'd increase the chance of ABI-compatibility problems remaining undetected during development and testing. best regards, Florian Pflug
pg_xml_errctxcheck.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
