Re: Another issue with invalid XML values - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Another issue with invalid XML values
Date
Msg-id 8657.1311688354@sss.pgh.pa.us
Whole thread Raw
In response to Re: Another issue with invalid XML values  (Florian Pflug <fgp@phlo.org>)
Responses Re: Another issue with invalid XML values
Re: Another issue with invalid XML values
List pgsql-hackers
Florian Pflug <fgp@phlo.org> writes:
> What's more, xml.c actually does attempt to protect against this situation
> by calling LIBXML_TEST_VERSION in pg_xml_init_library().

> But that check doesn't fire in our case, because it explicitly allows the
> actual library version to be newer than the header file version, as long
> as the major versions agree (the major version being "2" in this case).

> So in essence, libxml promises ABI backwards-compatibility, but breaks
> that promise when it comes to restoring the structured error context.

Fun.

> The only fix I can come up with is to explicitly test whether or not we're
> able to restore the structured error context in pg_xml_init_library().

Yeah, I think you are right.

> The downside of this is that a libxml version upgrade might break postgres,

Such an upgrade would break Postgres anyway --- better we are able to
detect and report it clearly than that we fail in bizarre ways.

>> As a side note, we don't add an rpath for libxml2 like we do for Perl and
>> Python.

> Sounds like we should change that.

I don't think so.  It would just be another headache for packagers ---
in Red Hat distros, at least, packages are explicitly forbidden from
containing any rpath settings.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Check constraints on partition parents only?
Next
From: Robert Haas
Date:
Subject: Re: psql: bogus descriptions displayed by \d+