Thread

Re: Add GUC to enable libxml2's XML_PARSE_HUGE

Erik Wienhold <ewie@ewie.name> — 2025-08-21T02:26:32Z

On 2025-08-20 21:42 +0200, Jim Jones wrote:
> On 20.08.25 17:46, Tom Lane wrote:
> > 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 totally forgot about that stance.  Is this only about adding new GUCs?
Because there are existing GUCs that change semantics, e.g. xmlbinary,
check_function_bodies.  I guess there's a trade-off between usefulness
and being error-prone/surprising to the user (POLA).

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

I guess the excuse for xmloption is that the SQL standard defines SET
XML OPTION.

> Would you see any other way, other than a GUC, to provide this
> feature?

Forking off the core XML code into an extension to provide a custom xml
data type with the desired parsing behavior? :(

-- 
Erik Wienhold