Erik Wienhold <ewie@ewie.name> writes:
> On 2024-07-06 16:25 +0200, Tom Lane wrote:
>> Yeah, apparently --- I get what look like the same diffs with
>> libxml2 2.13.0 recently supplied by MacPorts. Grumble.
>> Somebody's going to have to look into that.
> Here's a patch that fixes just the xmlserialize and namespace errors.
One angle that ought to be considered is that some of this stuff may
be flat-out bugs in 2.13.0. I see at
https://gitlab.gnome.org/GNOME/libxml2/-/releases
that both 2.13.1 and 2.13.2 contain fixes for "regressions" in 2.13.0.
I'm disinclined to spend much effort on working around dot-zero bugs.
> Use xmlAddChildList instead of xmlAddChild for xmlserialize. That also
> works with 2.12.7, but I don't know about older libxml2 versions. Maybe
> ...
> I don't know if using xmlAddChild in this context was ever correct.
Good question. A look at
https://github.com/ConradIrwin/libxml2/blame/master/include/libxml/tree.h
shows that xmlAddChildList has been there for decades, and I also
see in the 2.13.0 notes
* tree: Align xmlAddChild with other node insertion functions
so it sort of looks like this is something that we got away with
but it wasn't right. I'm inclined to just replace the call and see
what the buildfarm says.
> The namespace errors are tricky because xmlParseBalancedChunkMemory now
> returns res_code != 0 for invalid or unknown namespaces (probably other
> errors as well). So I just added an additional check to ignore those
> errors for >=2.13. But that's rather hackish. I don't know how to
> handle it in xml_errorHandler where those error codes are already dealt
> with in order to compensate for differences in error reporting across
> different libxml2 versions. Looks like xmlerrcxt is ignored by
> xmlParseBalancedChunkMemory.
2.13.0 mentions having added some new error-handler-setting functions;
maybe we need to use one of those to get xmlParseBalancedChunkMemory's
attention now?
> No idea how to deal with the remaining errors for invalid and undefined
> entities which appear to include less details now.
That's fairly annoying. One answer is to create a variant
expected-file, but the long-term maintenance costs could be high.
On the other hand, our xml support is a bit of a backwater, so
maybe it wouldn't be that bad.
regards, tom lane