Re: PostgreSQL vs SQL/XML Standards

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: PostgreSQL vs SQL/XML Standards
Дата
Msg-id CAFj8pRDW_vqQxoyEz31b5r_fQvzMzwOm=KaVjJtJDm12_wzxXQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PostgreSQL vs SQL/XML Standards  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: PostgreSQL vs SQL/XML Standards
Список pgsql-hackers


pá 8. 3. 2019 v 15:31 odesílatel Alvaro Herrera <alvherre@2ndquadrant.com> napsal:
On 2019-Mar-08, Pavel Stehule wrote:

> looks like error in xmlXPathCompiledEval function, that produce little bit
> broken result for XML_DOCUMENT_NODE type. I hadn't this problem with
> libxml2 2.7.6 64bit, but I seen this issue on same version on 32bit.
>
> Currently I had not fresh 32 bit system to check it.
>
> I found a workaround - in this case copy (and release xmlNode) is not
> necessary.

Hmm ... going over the libxml2 2.7.6 source, I noticed that
xmlFreeNodeList seem to get this right -- it uses xmlFreeDoc for
XML_DOCUMENT_NODE.  Maybe a sufficient answer is to change the
xmlFreeNode there to xmlFreeNodeList.

It fixes current issue, but I afraid so these two routines are not replaceable. xmlFreeNodeList doesn't release xmlFreeDtd, XML_ATTRIBUTE_NODE is not checked.

You can see, from xmlNodeGetContent, XML_DOCUMENT_NODE type should to ignore content value, and newer returns this value.  Other interesting is xmlXPathOrderDocElems where content is used for counting, and probably from there is -1.

Maybe we can call explicitly xmlFreeDoc instead xmlFreeNode

some like

if (cur_copy->type == XML_DOCUMENT_NODE)
  xmlFreeDoc((xmlDocPtr) cur_copy);
else
  xmlFreeNode(cur_copy);

This looks most correct fix for me. What do you think?

Pavel



--
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Should we increase the default vacuum_cost_limit?
Следующее
От: Jeff Janes
Дата:
Сообщение: Hash index initial size is too large given NULLs or partial indexes