Re: XMLATTRIBUTES vs. values of type XML

On fre, 2011-07-29 at 11:37 +0200, Florian Pflug wrote:
> On Jul28, 2011, at 22:51 , Peter Eisentraut wrote:
> > On ons, 2011-07-27 at 23:21 +0200, Florian Pflug wrote:
> >> On Jul27, 2011, at 23:08 , Peter Eisentraut wrote:
> >>> 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"))
> >>
> >> With both 9.1 and 9.2 this query returns
> >>
> >> xmlelement
> >> --------------------
> >> <t a="&amp;amp;"/>
> >>
> >> i.e. makes the value of "a" represent the *literal* string '&amp;', *not*
> >> the literal string '&'. Just to be sure there's no miss-understanding here
> >> - is this what you expect?
> >
> > Well, I expect it to fail.
>
> Now you've lost me. What exactly should fail under what circumstances?

To me, the best solution still appears to be forbidding passing values
of type xml to XMLATTRIBUTES, unless we find an obviously better
solution that is not, "I came up with this custom escape function that I
tweaked so that it appears to make sense".

> > Unfortunately, in the latest SQL/XML standard the final
> > answer it nested deep in the three other standards, so I don't have an
> > answer right now. But there are plenty of standards in this area, so
> > I'd hope that one of them can give us the right behavior, instead of us
> > making something up.
>
> Which standards to you have in mind there? If you can point me to a place
> where I can obtain them, I could check if there's something in them
> which helps.

In SQL/XML 2008, the actual behavior of XMLSERIALIZE is delegated to
"XSLT 2.0 and XQuery 1.0 Serialization". I'm not familiar with this
latter standard, but it appears to have lots of options and parameters,
one of which might help us.