Re: xpath improvement suggestion

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