Re: [HACKERS] xpath improvement suggestion

[Scott Bailey]

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


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers