Re: xpath improvement suggestion - Mailing list pgsql-hackers
From | Scott Bailey |
---|---|
Subject | Re: xpath improvement suggestion |
Date | |
Msg-id | 4B4CEAEC.3070309@comcast.net Whole thread Raw |
In response to | Re: xpath improvement suggestion (Arie Bikker <arie@abikker.nl>) |
Responses |
Re: xpath improvement suggestion
|
List | pgsql-hackers |
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
pgsql-hackers by date: