From: | Jim Jones <jim(dot)jones(at)uni-muenster(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Erik Wienhold <ewie(at)ewie(dot)name>, Michael Paquier <michael(at)paquier(dot)xyz> |
Subject: | Re: Add GUC to enable libxml2's XML_PARSE_HUGE |
Date: | 2025-08-20 19:42:27 |
Message-ID: | 86e1fd88-23ef-479a-899e-f3418c580049@uni-muenster.de |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Tom
Thanks for replying so quickly!
On 20.08.25 17:46, Tom Lane wrote:
> Given the spotty security history of libxml2, I can't really see
> how this wouldn't be enormously unsafe. Even as a superuser-only
> option, it seems like a bad idea.
I was under the impression that the status quo already exposes
PostgreSQL to these risks silently, depending on the libxml2
(xmlParseBalancedChunkMemory) version in use. Our rationale was that
making the feature explicit would at least render it visible, auditable,
and delegable by superusers. Of course, the documentation should clearly
warn about the risks.
> Independently of that, we have learned the hard way that GUCs
> that change application-visible query semantics are a bad idea.
> You cannot really argue that this wouldn't be one.
I share these concerns about changing query semantics through GUCs, but
I thought this case might not be so different from xmloption:
postgres=# SET xmloption TO document;
SET
postgres=# SELECT 'hello'::xml;
ERROR: invalid XML document
LINE 1: SELECT 'hello'::xml;
^
DETAIL: line 1: Start tag expected, '<' not found
hello
^
postgres=# SET xmloption TO content;
SET
postgres=# SELECT 'hello'::xml;
xml
-------
hello
(1 row)
Would you see any other way, other than a GUC, to provide this feature?
Thanks!
Best, Jim
From | Date | Subject | |
---|---|---|---|
Next Message | Kirk Wolak | 2025-08-20 19:52:25 | Re: date_trunc function in interval version |
Previous Message | Nathan Bossart | 2025-08-20 19:19:43 | Re: Don't treat virtual generated columns as missing statistics in vacuumdb --missing-stats-only |