Re: libxml2 author overwhelmed with security requests

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>, PostgreSQL-development <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: libxml2 author overwhelmed with security requests
Date: 2025-06-19 21:12:06
Message-ID: 1803697.1750367526@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> Own implementation of SQL/XML generating functions like XMLFOREST or
> XMLELEMENT should not be too
> difficult. Significantly more difficult problem is parsing of XML (more
> with namespaces), although some basic
> support for XMLTABLE should not be too hard too.

I don't think anybody really wants to roll our own XML parser.

> Isn't possible to call Rust code from C? Then maybe there are some
> possibility from Rust world
> https://github.com/ballsteve/xrust

Maybe. I think the fundamental problem here, similar to what we've
run into elsewhere, is that we chose a library to depend on without
thinking hard enough about whether it would be well-supported in the
long run. I see little reason to think that that risk would be less
for some random not-written-in-C implementation. If we want to
jump ship away from libxml2, we had better ask hard questions about
the new choice.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2025-06-20 00:02:00 Re: Issues with 2PC at recovery: CLOG lookups and GlobalTransactionData
Previous Message Pavel Stehule 2025-06-19 20:59:38 Re: libxml2 author overwhelmed with security requests