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 expression selecting 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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers