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
>> already of type XML.
>> To wit, if you do
>> SELECT XMLELEMENT(NAME "t", XMLATTRIBUTES('&'::XML AS "a"))
>> you get
>> <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.
In response to
pgsql-hackers by date
|Next:||From: Florian Pflug||Date: 2011-07-27 17:57:44|
|Subject: Re: PQescapeByteaConn - returns wrong string for PG9.1 Beta3|
|Previous:||From: Robert Haas||Date: 2011-07-27 17:30:47|
|Subject: Re: sinval synchronization considered harmful|