Re: Add GUC to enable libxml2's XML_PARSE_HUGE
От | Jim Jones |
---|---|
Тема | Re: Add GUC to enable libxml2's XML_PARSE_HUGE |
Дата | |
Msg-id | 86e1fd88-23ef-479a-899e-f3418c580049@uni-muenster.de обсуждение исходный текст |
Ответ на | Re: Add GUC to enable libxml2's XML_PARSE_HUGE (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Add GUC to enable libxml2's XML_PARSE_HUGE
|
Список | pgsql-hackers |
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 already exposes PostgreSQL to these risks silently, depending on the libxml2 (xmlParseBalancedChunkMemory) version in use. Our rationale was that making the feature explicit would at least render it visible, auditable, and delegable by superusers. Of course, the documentation should clearly warn about the risks. > 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 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) Would you see any other way, other than a GUC, to provide this feature? Thanks! Best, Jim
В списке pgsql-hackers по дате отправления: