Re: XMLATTRIBUTES vs. values of type XML

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="&amp;"/> 
> 
> 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