Bug in XPATH() produces invalid XML values and probably un-restorable dumps

Поиск
Список
Период
Сортировка
От Florian Pflug
Тема Bug in XPATH() produces invalid XML values and probably un-restorable dumps
Дата
Msg-id 6F4E39D6-98D7-448E-ABC1-3A52CF884904@phlo.org
обсуждение исходный текст
Ответы Re: Bug in XPATH() produces invalid XML values and probably un-restorable dumps
Список pgsql-hackers
Hi

While trying to figure out sensible semantics for XPATH() and scalar-value returning XPath expressions, I've stumbled
upona bug in XPATH() that allows invalid XML values to be produced. This is a serious problem because should such
invalidvalues get inserted into an XML column, an un-restorable dump ensues. 

Here's an example (REL9_0_STABLE as of a few days ago)

template1=# SELECT (XPATH('/*/text()', '<root><</root>'))[1];
 xpath
-------
 <

Since XPATH() returns XML[], this value has type XML, but clearly isn't well-formed. And behold, casting to TEXT and
backto XML complains loudly. 

template1=# SELECT (XPATH('/*/text()', '<root><</root>'))[1]::TEXT::XML;
ERROR:  invalid XML content
DETAIL:  Entity: line 1: parser error : StartTag: invalid element name
    <
     ^

The culprit is xml_xmlnodetoxmltype() in backend/utils/adt/xml.c. For non-element nodes, it returns the result of
xmlXPathCastNodeToString()verbatim, even though that function doesn't reverse the entity replacement that was done
duringparsing. Adding a call to escape_xml()  
for non-element nodes fixes the problem

template1=# SELECT (XPATH('/*/text()', '<root><</root>'))[1];
 xpath
-------
 <

Patch is attached.

best regards,
Florian Pflug

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: Getting a bug tracker for the Postgres project
Следующее
От: Cédric Villemain
Дата:
Сообщение: Re: Getting a bug tracker for the Postgres project