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

Re: xpath processing brain dead

From: Hannu Krosing <hannu(at)2ndQuadrant(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>
Subject: Re: xpath processing brain dead
Date: 2009-02-27 23:37:51
Message-ID: 1235777871.7189.21.camel@huvostro (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, 2009-02-27 at 16:37 -0500, Andrew Dunstan wrote:
> Hannu Krosing wrote:
> > On Thu, 2009-02-26 at 13:51 -0500, Robert Haas wrote:
> >   
> >>> What I have proposed for 8.3 should not break a single case that currently
> >>> behaves usefully. If anyone has a counter-example please show it.
> >>>
> >>> What I have proposed for 8.4 possibly would break current "useful" behaviour
> >>> (FSVO "useful"), but should be done anyway on correctness grounds.
> >>>       
> >> I dunno, aren't XML document fragments sort of a pretty common case?
> >>     
> >
> > I'd rather argue that xml datatype should not even accept anything but
> > complete xml documents. Same as int field does not accept int[].
> >
> > Or maybe we rather need separate xmldocument and xmlforest/xmlfragments
> > types in next releases and leave the "base" xml as it is but deprecated
> > due to inability to fix it without breaking backwards compatibility.
> >
> >   
> Some of the functions, including some specified in the standard, produce 
> fragments. That's why we have the 'IS DOCUMENT' test.

But then you could use xmlfragments as the functions return type, no ?

Does tha standard require that the same field type must store both
documents and fragments ?

> You can also force validation as a document by saying  SET XML OPTION 
> cheers
> andrew
Hannu Krosing
PostgreSQL Scalability and Availability 
   Services, Consulting and Training

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2009-02-27 23:39:38
Subject: Re: add_path optimization
Previous:From: Tom LaneDate: 2009-02-27 23:30:29
Subject: pgsql: Temporarily (I hope) disable flattening of IN/EXISTS sublinks

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