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
