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