Skip site navigation (1) Skip section navigation (2)

Re: XMLATTRIBUTES vs. values of type XML

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Florian Pflug <fgp(at)phlo(dot)org>
Cc: PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: XMLATTRIBUTES vs. values of type XML
Date: 2011-07-28 20:51:36
Message-ID: 1311886296.6651.3.camel@vanquo.pezone.net (view raw or flat)
Thread:
Lists: pgsql-hackers
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 '&amp;'::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.

> What's the workaround if you have a value of type XML, e.g. '&amp;',
> 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.  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.



In response to

Responses

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2011-07-28 20:54:14
Subject: Re: cheaper snapshots
Previous:From: Robert HaasDate: 2011-07-28 20:42:38
Subject: Re: cheaper snapshots

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group