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

Thank you all so very much for your valuable comments.

So we can be take it for granted that, the behavior of CDATA will remain as it is currently now in pg12 and we need change our queries accordingly to handle this from now on.

Thanks again,
Mostafa
________________________________
From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Sent: Tuesday, November 5, 2019 10:28 PM
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Chapman Flack <chap(at)anastigmatix(dot)net>; mostafa_bit0108(at)hotmail(dot)com <mostafa_bit0108(at)hotmail(dot)com>; PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>; Markus Winand <markus(dot)winand(at)winand(dot)at>
Subject: Re: BUG #16046: xpath returns CDATA tag along with the value in postgres 12

pá 25. 10. 2019 v 19:28 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us<mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us>> napsal:
Chapman Flack <chap(at)anastigmatix(dot)net<mailto:chap(at)anastigmatix(dot)net>> writes:
> On 10/24/19 19:14, Chapman Flack wrote:
>> Which may or may not be a good thing. Perhaps it could lead the unwary
>> in some cases to think such a query is giving a directly usable
>> text string back, which will be harmless until the one time a value
>> with escaping comes back. (The no-surprises way to get back a directly
>> usable text string, if that's what's wanted, would be with XMLTABLE
>> and an output column of text type.)

> If the original reporter is happy with getting xml back, instead of
> raw text, but only wants the form of escaping to be the same as it was
> in pg11, the xpath //cname/aname/text() can just be rewritten as
> string(//cname/aname), which will lose any CDATA-ness and consistently
> produce the form where individual characters are escaped, in 11 or 12.

> I think.

Yeah, that does work the same for me in 11 and HEAD:

regression=# SELECT unnest(xpath('string(//cname/aname)','<cname><aname><![CDATA[select 5>4]]></aname></cname>'::xml));
unnest
---------------
select 5&gt;4
(1 row)

So I'm inclined to write this off as an intended, or at least not
unwanted, change. However, this complaint does reinforce Alvaro's
original choice not to back-patch 251cf2e27.

The v12 release notes don't call this out as a compatibility issue,
nor mention anything about CDATA handling:

* Fix assorted bugs in XML functions (Pavel Stehule, Markus Winand,
Chapman Flack)

Specifically, in XMLTABLE, xpath(), and xmlexists(), fix some cases
where nothing was output for a node, or an unexpected error was
thrown, or necessary escaping of XML special characters was omitted.

Should we extend that item (if so, what to say exactly?) and/or move
it into the "Observe the following incompatibilities" list?

I tested XMLTABLE function, and it is work how it is expected. About xpath function - I don't know - there is a agreement so result is correct, and I can say so form of result of Postgres 12 is maybe little bit better, because you will get raw result without any transformation, what is sense of CDATA tag. Unfortunately, I agree, so this behave can surprise for developers and it's clear incompatible behave. Trimming CDATA tag or using string function is easy.

Somewhere should be strong warning about change of processing of CDATA nodes - originally these nodes was converted to text and escaped, now they returned in raw format - without any conversions. The example with "string" function should be used there.

Regards

Pavel

regards, tom lane