PG versus libxml2 2.12.x

On 2024-01-27 Sa 14:04, Tom Lane wrote:

Buildfarm member caiman has been failing build for a couple weeks now.
The reason turns out to be that recent libxml2 has decided to throw
a "const" into the signature required for custom error handlers.
(API compatibility? What's that?)

I don't mind adopting the "const" --- it's a good idea in isolation.
The trouble is in fixing our code to work with both old and new
libxml2 versions. We could thrash around with a configure test or
something, but I think the most expedient answer is just to insert
some explicit casts, as shown in the attached. It's possible though
that some compilers will throw a cast-away-const warning. I'm
not seeing any, but ...

Also, I'm seeing a deprecation warning in contrib/xml2/xpath.c
for

xmlLoadExtDtdDefaultValue = 1;

I'm not sure why that's still there, given that we disabled external
DTD access ages ago. I propose we just remove it.

In short, I suggest the attached.

Looks reasonable.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

On 27.01.24 20:04, Tom Lane wrote:

Buildfarm member caiman has been failing build for a couple weeks now.
The reason turns out to be that recent libxml2 has decided to throw
a "const" into the signature required for custom error handlers.
(API compatibility? What's that?)

I don't mind adopting the "const" --- it's a good idea in isolation.
The trouble is in fixing our code to work with both old and new
libxml2 versions. We could thrash around with a configure test or
something, but I think the most expedient answer is just to insert
some explicit casts, as shown in the attached. It's possible though
that some compilers will throw a cast-away-const warning. I'm
not seeing any, but ...

In PL/Tcl, we used to have these CONST84 and CONST86 things, for similar
reasons. Maybe that would be another approach.

Peter Eisentraut <peter@eisentraut.org> writes:

On 27.01.24 20:04, Tom Lane wrote:

I don't mind adopting the "const" --- it's a good idea in isolation.
The trouble is in fixing our code to work with both old and new
libxml2 versions. We could thrash around with a configure test or
something, but I think the most expedient answer is just to insert
some explicit casts, as shown in the attached. It's possible though
that some compilers will throw a cast-away-const warning. I'm
not seeing any, but ...

In PL/Tcl, we used to have these CONST84 and CONST86 things, for similar
reasons. Maybe that would be another approach.

Yeah, if the simple cast approach turns out to create warnings,
we'll have to fall back on using actually different declarations.
I'm hoping to not have to go there.

regards, tom lane

I wrote:

Peter Eisentraut <peter@eisentraut.org> writes:

In PL/Tcl, we used to have these CONST84 and CONST86 things, for similar
reasons. Maybe that would be another approach.

Yeah, if the simple cast approach turns out to create warnings,
we'll have to fall back on using actually different declarations.
I'm hoping to not have to go there.

Actually ... what I really want to avoid is adding a configure test.
The alternative to that would be an #if test on LIBXML_VERSION,
which I'd initially not wanted to do ... but I now notice that
we already have one of those for a nearby purpose (coping with a
different change in libxml2's error APIs). So adding another one
of those doesn't seem so bad after all. I now like the attached
approach better.

regards, tom lane