Обсуждение: Fix deprecation warning with libxml2 2.14 in contrib/xml2/

Hi all,

A colleague, Walid Abrahim, has reported that contrib/xml2/ gives a
deprecation warning when attempting to compile xpath.c with upstream
libxml2 2.14 (just checkout the top of branch 2.14):
xpath.c: In function ‘pgxmlNodeSetToText’:
xpath.c:212:17: warning: ‘content’ is deprecated [-Wdeprecated-declarations]
  212 |                 result = xmlStrdup(buf->content);
      |                 ^~~~~~
In file included from /home/pooh/stable/libxml/2.14/include/libxml/parser.h:16,
                 from /home/pooh/stable/libxml/2.14/include/libxml/tree.h:17,
                 from /home/pooh/stable/libxml/2.14/include/libxml/xpath.h:27,
                 from xpath.c:19:
/home/pooh/stable/libxml/2.14/include/libxml/tree.h:103:14: note: declared here
  103 |     xmlChar *content XML_DEPRECATED_MEMBER;
      |              ^~~~~~~

This is caused by the following commit, where upstream is deciding
that we should not directly look at the "content" field of an
xmlBuffer:
https://github.com/GNOME/libxml2/commit/b34dc1e4

The solution is simple: we need to replace buf->content by a call to
xmlBufferContent().  This routine exists since be803967dbec (year
2000), so 25 years should make that safe enough to use.

The last batch of libxml deprecation warning fixes we have done was
last year in [1], so the one we have here is new.  It seems to me that
it would not hurt to just backpatch that all the way down rather than
waiting.  Comments are welcome.

[1] https://www.postgresql.org/message-id/1012981.1713222862@sss.pgh.pa.us

Regards,
--
Michael

On Fri, Jul 04, 2025 at 01:03:01PM +0900, Michael Paquier wrote:
> A colleague, Walid Abrahim, has reported that contrib/xml2/ gives a

Oops, Walid Ibrahim.  Sorry for the mistake.
--
Michael

Michael Paquier <michael@paquier.xyz> writes:
> The solution is simple: we need to replace buf->content by a call to
> xmlBufferContent().  This routine exists since be803967dbec (year
> 2000), so 25 years should make that safe enough to use.

> The last batch of libxml deprecation warning fixes we have done was
> last year in [1], so the one we have here is new.  It seems to me that
> it would not hurt to just backpatch that all the way down rather than
> waiting.  Comments are welcome.

Seems reasonable.

            regards, tom lane

On 04.07.25 06:03, Michael Paquier wrote:
> The solution is simple: we need to replace buf->content by a call to
> xmlBufferContent().  This routine exists since be803967dbec (year
> 2000), so 25 years should make that safe enough to use.
>
> The last batch of libxml deprecation warning fixes we have done was
> last year in [1], so the one we have here is new.  It seems to me that
> it would not hurt to just backpatch that all the way down rather than
> waiting.  Comments are welcome.

+1

-- 
Jim

On Fri, Jul 04, 2025 at 12:44:56AM -0400, Tom Lane wrote:
>> The last batch of libxml deprecation warning fixes we have done was
>> last year in [1], so the one we have here is new.  It seems to me that
>> it would not hurt to just backpatch that all the way down rather than
>> waiting.  Comments are welcome.
>
> Seems reasonable.

Thanks, applied.
--
Michael