Re: xpath improvement suggestion

Arie Bikker wrote:
> Peter Eisentraut wrote:
>> On ons, 2010-01-06 at 23:46 +0100, Arie Bikker wrote:
>>  
>>> Hope this is the right attachement type (I'm new at this)
>>> BTW. here a some nice examples:
>>>
>>> - Get the number of attributes of the first childnode:
>>>
>>> select ( xpath('count(@*)',(xpath('*[1]','<a b="c"><d e="f" 
>>> g="j"/></a>'))[1]))[1];
>>>
>>> - an alternative for xpath_exist('/a/d')
>>> select (xpath('boolean(/a/d)','<a b="c"><d e="f" g="j"/></a>'))[1];
>>>
>>> - fixes bug 4206
>>>
>>> select xpath('//text()',xmlparse(document '<?xml 
>>> version="1.0"?><elem1><elem2>one</elem2><elem2>two</elem2><elem2>three</elem2><elem3att="2"/></elem1>')); 
>>>
>>>
>>> - fixes bug 4294
>>>
>>> select xpath('name(/my:a/*[last()])', '<a 
>>> xmlns="http://myns.com/ns"><b>text1</b><c>text2</c></a>', 
>>> ARRAY[ARRAY['my','http://myns.com/ns']]);     
>>
>> Instead of converting everything to text, there have been previous
>> suggestions to add functionx like xpath_string, xpath_number,
>> xpath_boolean that return the appropriate types from xpath.  This could
>> provide for better type safety and probably also more clarity.
>>
>> In any case, please consider adding test cases like the above to the
>> regression tests in whatever patch comes out at the end.
>>
>>   
> As an addition these xpath_sometype functions have been mentioned and 
> can be handy. But, considering that the xpath function itself is a 
> generalized function, the user of this function might not have 
> beforehand knowledge of the type of the result; the first argument of 
> the call could be used in a dynamic fashion.
> Comming back to the xpath_sometype functions - would these definitions 
> be suitable?
> 
> boolean xpath_boolean(xpath, xml [, nsarray])
> text xpath_string(xpath, xml [, nsarray])
> int xpath_number(xpath, xml [,nsarray])
> 
> implementation can be done via an xpath_nonnode function defined as:
> text xpath_nonnode(xpath, xml [,nsarray])
> where each of the xpath_sometype functions simply interpret the text as 
> its target type.
> Is this the way to go?
> 
> kind regards,  Arie Bikker

Postgres' type system is MUCH more robust than anything in XPath/XML. 
And folks who use XML on a regular basis expect most XPath expressions 
to return a string any way.

For instance how many confused users do you think you'll get with 
something like:
SELECT xpath_boolean('boolean(/root/@bar)', '<root bar="false"/>)
-- evaluates to true

or

SELECT xpath_number('/root/@foo', '<root foo="42"/>')
--xpath will return the string '42' not a number unless you do something 
like:
SELECT xpath_number('number(/root/@foo)', '<root foo="42"/>')

I think we'd be much better of having a function like xpath_nonnode() or 
xpath_value() that returns text and let the user handle the casting.


Scott Bailey