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
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 |