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

Chapman Flack <chap@anastigmatix.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