Re: BUG #16046: xpath returns CDATA tag along with the value in postgres 12

From: Chapman Flack <chap(at)anastigmatix(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, mostafa_bit0108(at)hotmail(dot)com
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org, Markus Winand <markus(dot)winand(at)winand(dot)at>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Subject: Re: BUG #16046: xpath returns CDATA tag along with the value in postgres 12
Date: 2019-10-24 23:34:09
Message-ID: 5DB234F1.1040706@anastigmatix.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 10/24/19 19:14, Chapman Flack wrote:
> <![CDATA[select 5 & 6 <yahoo!>]]>
> select 5 &amp; 6 &lt;yahoo!&gt;
>
> Either form of result is correct, and having it respect the form that was
> used in the input might even be delightfully smart.
>
> I haven't looked in the code just now to see if it is intentionally being
> delightfully smart, or more simplistic-and-lucky.

It appears to be probably unintentional-but-ok: libxml tags a CDATA
section differently (XML_CDATA_SECTION_NODE) than a text node
(XML_TEXT_NODE), so a CDATA node falls into the catch-all branch of

if (cur->type != XML_ATTRIBUTE_NODE && cur->type != XML_TEXT_NODE)

where it gets dumped faithfully by xmlNodeDump(), with the upshot
that the result always will be well-formed XML, and will respect whether
the input was supplied as CDATA or not. We could choose to say that's
what we meant it to do all along.

Regards,
-Chap

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andres Freund 2019-10-25 01:04:56 Re: BUG #16076: JIT causes huge delays in a complex query. jit=off solves it.
Previous Message Chapman Flack 2019-10-24 23:14:48 Re: BUG #16046: xpath returns CDATA tag along with the value in postgres 12