On ons, 2011-07-27 at 19:37 +0200, Florian Pflug wrote:
> > 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.
Well, offhand I would expect that passing an XML value to XMLATTRIBUTES
would behave as in
SELECT XMLELEMENT(NAME "t", XMLATTRIBUTES(XMLSERIALIZE(content '&'::XML AS text) AS "a"))
which is what it indeed does in 9.1.
So if we don't want to restrict this, for backward compatibility, then I
would suggest that we fix it to work like it used to.
I would be very hesitant about adding another escape mechanism that
escapes some things but not others. We already have two or three of
those for XML, and it doesn't seem worth adding another one just for
this, which is outside the standard and for which a valid workaround
exists.