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 & 6 <yahoo!>
>
> 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
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 |