Re: Add GUC to enable libxml2's XML_PARSE_HUGE - Mailing list pgsql-hackers

From Jim Jones
Subject Re: Add GUC to enable libxml2's XML_PARSE_HUGE
Date
Msg-id 86e1fd88-23ef-479a-899e-f3418c580049@uni-muenster.de
Whole thread Raw
In response to Re: Add GUC to enable libxml2's XML_PARSE_HUGE  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Add GUC to enable libxml2's XML_PARSE_HUGE
List 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



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Don't treat virtual generated columns as missing statistics in vacuumdb --missing-stats-only
Next
From: Kirk Wolak
Date:
Subject: Re: date_trunc function in interval version