Re: BUG #8469: Xpath behaviour unintuitive / arguably wrong

On 2013-10-05 Broce Monjian wrote:
> On Fri, Oct  4, 2013 at 10:20:46PM +0200, Stefan Kaltenbrunner wrote:
> > > > =
http://www.postgresql.org/message-id/201106291934.23089.rsmogura@softperie=
nce.eu
> > >=20
> > > There are two other similar bug reports on this from February and =
March
> > > of this year:
> > >=20
> > > =
http://www.postgresql.org/message-id/E1U1FKL-0002rD-RO@wrihigleys.postgres=
ql.org
> > I think that should be:
> > =
http://www.postgresql.org/message-id/E1U1FKL-0002rD-RO@wrigleys.postgresql=
.org

> > > =
http://www.postgresql.org/message-id/E1UHyUw-0001oj-HE@wrigleys.postgresql=
.org

> > > Someone who knows XML needs to take leadership on this and propose =
a
> > > patch.

>  Added to TODO.

I'm the one who submitted the patch which changed XPATH's behaviour. =
While I agree
that some might find it counter-intuitive for an XPATH expression like =
//node/text()
to return quoted output, there's really no way around that given the way =
the postgres
type system works.

A general XPATH function needs to return XML[], not TEXT[], since an =
XPATH can not
only select text and attribute nodes, but whole XML subtrees. But if it =
returns XML,
it NEEDS to return something that's actually valid content for a value =
of type XML,
not plain test masquerading as XML. Otherwise, basic guarantees are =
violated, like
for example that xmlin(xmlout(value)) yields value (and not an error).

So unfortunate as it may be, I really see no way around the current =
behaviour. We
could (and should) however

  * Provide an way to actually unescape text contained in XML fields. I =
planned to
    post a followup patch doing that when I submitted the patch for =
XPATH, but then
    stuff came up and=85 oh well=85 :-(

  * Add a big, fat warning to the docs about this.=20

best regards,
Florian Pflug

PS: I'm not subscribed to pgsql-bugs, so please keep me on the CC list