Re: proposal casting from XML[] to int[], numeric[], text[] - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: proposal casting from XML[] to int[], numeric[], text[]
Date
Msg-id 200711032220.lA3MKPR15985@momjian.us
Whole thread Raw
In response to Re: proposal casting from XML[] to int[], numeric[], text[]  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold

---------------------------------------------------------------------------

Andrew Dunstan wrote:
> 
> 
> Peter Eisentraut wrote:
> > Am Freitag, 28. September 2007 schrieb Nikolay Samokhvalov:
> >   
> >> what should be returned for XML like "<em><strong>PostgreSQL</strong>
> >> is a powerful, open source relational database system</em>" if user
> >> requests for text under "em" node? In XML world, the correct answer is
> >> "PostgreSQL  is a powerful, open source relational database system" --
> >> concatenation of all strings from the node itself and all its
> >> descendants, in the correct order. Will be this expected for RDBMS
> >> users?).
> >>     
> >
> > Well, if that is the defined behavior for XPath, then that's what we should 
> > do.
> >
> >   
> 
> The xpath string value of a single node is the concatentation of the 
> text children of the node and all its children in document order, IIRC. 
> But that's not what we're dealing with here. xpath() doesn't return a 
> single node but a node set (or so say the docs). The string value of a 
> node set is in effect the string value of its first member, which seems 
> less than useful in this context, or at least no great guide for us.
> 
> I think there's probably a good case for a cast from xml[] to text[] if 
> we don't have one.
> 
> cheers
> 
> andrew
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: CREATE CONSTRAINT TRIGGER compatibility issue
Next
From: Tom Lane
Date:
Subject: Re: building 8.3beta2 w/ 'make check' consumes A LOT of disk space