| From: | Jim Jones <jim(dot)jones(at)uni-muenster(dot)de> |
|---|---|
| To: | Erik Wienhold <ewie(at)ewie(dot)name> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz> |
| Subject: | Re: Add GUC to enable libxml2's XML_PARSE_HUGE |
| Date: | 2025-08-21 12:17:19 |
| Message-ID: | 1f3eca95-c9ba-4fd1-8c7b-01c86aea2408@uni-muenster.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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 succeeds or fails, which is pretty much what would
happen with xml_parse_huge.
>> 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? :(
That could work. I'm just afraid it would be too much trouble just to
enable text nodes larger than 10MB.
Regards, Jim
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dmitry | 2025-08-21 13:30:09 | Inconsistent update in the MERGE command |
| Previous Message | Frédéric Yhuel | 2025-08-21 12:02:40 | Re: [BUG] temporary file usage report with extended protocol and unnamed portals |