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="&"/>
>>
>> i.e. makes the value of "a" represent the *literal* string '&', *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?
>> What's the workaround if you have a value of type XML, e.g. '&',
>> and want to set an attribute to the value represented by that XML fragment
>> (i.e. '&')? Since we have no XMLUNESCAPE function, I don't see an easy
>> way to do that. Maybe I'm missing something, though.
>
> It may be worth researching whether the XMLSERIALIZE function is
> actually doing what it should, or whether it could/should do some
> unescaping.
I don't see how that could work. It can't unescape anything in e.g.
'<t>&</t>', because the result would be a quite useless not-really-XML
kind of thing. It could unescape '&' but that kind of content-dependent
behaviour seem even worse than my proposed escaping rules for XMLATTRIBUTES.
> 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.
best regards,
Florian Pflug
