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>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