Re: Add GUC to enable libxml2's XML_PARSE_HUGE

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

In response to

Responses

Browse pgsql-hackers by date

  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