On Jul27, 2011, at 16:18 , Peter Eisentraut wrote:
> On tis, 2011-07-26 at 22:44 +0200, Florian Pflug wrote:
>> While reviewing the (now applied) XPATH escaping patches, Radoslaw
>> found one
>> case where the previous failure of XPATH to escape its return value
>> was offset
>> by XMLATTRIBUTES insistence to escape all input values, even if
>> they're
>> already of type XML.
>>
>> To wit, if you do
>>
>> SELECT XMLELEMENT(NAME "t", XMLATTRIBUTES('&'::XML AS "a"))
>>
>> you get
>>
>> xmlelement
>> --------------------
>> <t a="&"/>
>
> Per SQL standard, the attribute values may not be of type XML, so maybe
> we should just prohibit it.
We probably should have, but I think it's too late for that. I don't
believe I'm the only one who uses XPATH results as attribute values,
and we'd severely break that use-case.
You might say the same thing about my proposal, of course, but I believe
the risk is much smaller there. Applications would only break if they (a) Pass XML from a source other than a XPath
expressionselecting a text or attribute and (b) actually want double-escaping to occur.
As a data point, I've written an application with makes heavy use of
our XML infrastructure over the last few months (as you might have guessed
from the stream of patches ;-)). That application would be pretty much
untroubled by the changes to XMLATTRIBUTES I proposed, but would be
severely broken if we rejected values of type XML all together.
best regards,
Florian Pflug
