Re: XMLATTRIBUTES vs. values of type XML

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?

> 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.

There's currently no difference in behaviour between 9.1 and 9.2 there.
We've only modified XPATH to always correctly escape it's result in 9.2,
so there's only a difference if you pass the result of XPATH() to
XMLATTRIBUTES. Which I figured to be the most likely reason for to pass
values of type XML to XMLATTRIBUTES, but maybe you disagree there.

> 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.

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.

best regards,
Florian Pflug