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

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

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
>