Horton

Thread

Commits

  1. Fix incompatibilities with libxml2 >= 2.12.0.

  1. PG versus libxml2 2.12.x

    Tom Lane <tgl@sss.pgh.pa.us> — 2024-01-27T19:04:22Z

    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.

			regards, tom lane

  2. Re: PG versus libxml2 2.12.x

    Andrew Dunstan <andrew@dunslane.net> — 2024-01-29T13:30:04Z

    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

  3. Re: PG versus libxml2 2.12.x

    Peter Eisentraut <peter@eisentraut.org> — 2024-01-29T14:56:12Z

    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.

  4. Re: PG versus libxml2 2.12.x

    Tom Lane <tgl@sss.pgh.pa.us> — 2024-01-29T15:19:47Z

    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

  5. Re: PG versus libxml2 2.12.x

    Tom Lane <tgl@sss.pgh.pa.us> — 2024-01-29T15:59:06Z

    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