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

Chapman Flack <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?

regards, tom lane