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
