On 21.08.25 04:26, Erik Wienhold wrote:
> I guess the excuse for xmloption is that the SQL standard defines SET
> XML OPTION.
I guess you're right... in this case the standard dictates what should
be done. It just doesn't change the fact that depending on the parameter
value the same query succ
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
On Wed, Aug 20, 2025 at 11:46:11AM -0400, 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.
For reference: a famous example of that is autocommit as
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 alre
Jim Jones writes:
> To address this, Erik and I would like to propose a new GUC,
> xml_parse_huge, which controls libxml2’s XML_PARSE_HUGE option.
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 li
i-muenster.de#1cfece11b1d62fbd43ed644e1f9710e2
Best regards, JimFrom 808586b86ec434657fa3b5c226109f6868975dcb Mon Sep 17 00:00:00 2001
From: Jim Jones
Date: Mon, 18 Aug 2025 13:08:30 +0200
Subject: [PATCH v1] Add GUC to enable libxml2's XML_PARSE_HUGE option
This patch introduces the configur
