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

From Andrew Dunstan
Subject Re: proposal casting from XML[] to int[], numeric[], text[]
Date
Msg-id 470A1C37.60800@dunslane.net
Whole thread Raw
In response to Re: proposal casting from XML[] to int[], numeric[], text[]  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: proposal casting from XML[] to int[], numeric[], text[]
List pgsql-hackers

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


pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Another Idea: Try Including snapshot with TOAS (was: Including Snapshot Info with Indexes)
Next
From: Simon Riggs
Date:
Subject: Re: Another Idea: Try Including snapshot with TOAS (was: Including Snapshot Info with Indexes)