xpath improvement suggestion
in [PgSql]
|
From: Scott Bailey on 5 Jan 2010 19:34 Arie Bikker wrote: > Hi all, > > Well I had to burn some midnight oil trying to figure out why a > construct like > SELECT xpath('name()','<a/>'); > doesn't give the expected result. Kept getting an empty array: > xpath > ------------- > {} > instead of the expected "{a}" > BugID 4294 and the TODO item "better handling of XPath data types" > pointed in the right direction. > whithin src/backend/utils/adt/xml.c in the function xpath the result of > the call to xmlXPathCompiledEval is not handled optimally. In fact, the > result is assumed to be a nodeset without consulting the ->type member > of the result. I've made some minor changes to xml.c to handle some > non-nodeset results of xmlXPathCompiledEval. > Essentially, the revised code makes an array of all the nodes in the > xpathobj result in case this is a nodeset, or an array with a single > element in case the reult is a number/string/boolean. The problem cases > mentioned in > http://archives.postgresql.org/pgsql-hackers/2008-06/msg00616.php now > work as expected. > Revision of the code involves: > - A switch statement to handle the result type of xmlXPathCompiledEval. > - an additional function xmlpathobjtoxmltype. > > diff of the revisioned code with respect to original is in attached file. > > kind regards, Arie Bikker Well that's interesting. I was getting ready to dig into libxml2 to see what it would take to return scalar values from xpath expressions. Thanks. Scott -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 5 Jan 2010 21:54 On Tue, Jan 5, 2010 at 6:09 PM, Arie Bikker <arie(a)abikker.nl> wrote: > Hi all, > > Well I had to burn some midnight oil trying to figure out why a construct > like > SELECT xpath('name()','<a/>'); > doesn't give the expected result. Kept getting an empty array: > xpath > ------------- > {} > instead of the expected "{a}" > BugID 4294 and the TODO item "better handling of XPath data types" pointed > in the right direction. > whithin src/backend/utils/adt/xml.c in the function xpath the result of the > call to xmlXPathCompiledEval is not handled optimally. In fact, the result > is assumed to be a nodeset without consulting the ->type member of the > result. I've made some minor changes to xml.c to handle some non-nodeset > results of xmlXPathCompiledEval. > Essentially, the revised code makes an array of all the nodes in the > xpathobj result in case this is a nodeset, or an array with a single element > in case the reult is a number/string/boolean. The problem cases mentioned in > http://archives.postgresql.org/pgsql-hackers/2008-06/msg00616.php now work > as expected. > Revision of the code involves: > - A switch statement to handle the result type of xmlXPathCompiledEval. > - an additional function xmlpathobjtoxmltype. > > diff of the revisioned code with respect to original is in attached file. > > kind regards, Arie Bikker Hi, Could you please resend this as a context diff and add it to our patch management application? http://wiki.postgresql.org/wiki/Submitting_a_Patch https://commitfest.postgresql.org/action/commitfest_view/open Thanks! ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Arie Bikker on 6 Jan 2010 16:59 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Robert Haas wrote: <blockquote cite="mid:603c8f071001051854x10875b50vf620a3fca727ab11(a)mail.gmail.com" type="cite"> <pre wrap="">On Tue, Jan 5, 2010 at 6:09 PM, Arie Bikker <a class="moz-txt-link-rfc2396E" href="mailto:arie(a)abikker.nl"><arie(a)abikker.nl></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">Hi all, Well I had to burn some midnight oil trying to figure out why a construct like SELECT xpath('name()','<a/>'); doesn't give the expected result. Kept getting an empty array: xpath ------------- {} instead of the expected "{a}" BugID 4294 and the TODO item "better handling of XPath data types" pointed in the right direction. whithin src/backend/utils/adt/xml.c in the function xpath the result of the call to xmlXPathCompiledEval is not handled optimally. In fact, the result is assumed to be a nodeset without consulting the ->type member of the result. I've made some minor changes to xml.c to handle some non-nodeset results of xmlXPathCompiledEval. Essentially, the revised code makes an array of all the nodes in the xpathobj result in case this is a nodeset, or an array with a single element in case the reult is a number/string/boolean. The problem cases mentioned in <a class="moz-txt-link-freetext" href="http://archives.postgresql.org/pgsql-hackers/2008-06/msg00616.php">http://archives.postgresql.org/pgsql-hackers/2008-06/msg00616.php</a> now work as expected. Revision of the code involves: - A switch statement to handle the result type of xmlXPathCompiledEval. - an additional function xmlpathobjtoxmltype. diff of the revisioned code with respect to original is in attached file. kind regards, Arie Bikker </pre> </blockquote> <pre wrap=""><!----> Hi, Could you please resend this as a context diff and add it to our patch management application? <a class="moz-txt-link-freetext" href="http://wiki.postgresql.org/wiki/Submitting_a_Patch">http://wiki.postgresql.org/wiki/Submitting_a_Patch</a> <a class="moz-txt-link-freetext" href="https://commitfest.postgresql.org/action/commitfest_view/open">https://commitfest.postgresql.org/action/commitfest_view/open</a> Thanks! ....Robert </pre> </blockquote> Hope this is the right attachement type (I'm new at this)<br> BTW. here a some nice examples:<br> <br> - Get the number of attributes of the first childnode:<br> <tt>select ( xpath('count(@*)',(xpath('*[1]','<a b="c"><d e="f" g="j"/></a>'))[1]))[1];<br> <br> </tt>- an alternative for xpath_exist('/a/d')<br> <tt>select (xpath('boolean(/a/d)','<a b="c"><d e="f" g="j"/></a>'))[1];<br> <br> </tt>- fixes bug 4206<br> <tt>select xpath('//text()',xmlparse(document '<?xml version="1.0"?><elem1><elem2>one</elem2><elem2>two</elem2><elem2>three</elem2><elem3</tt><tt>att="2"/></elem1>'));<br> </tt><tt><br> </tt>- fixes bug 4294<br> <tt>select xpath('name(/my:a/*[last()])', '<a xmlns=<a class="moz-txt-link-rfc2396E" href="http://myns.com/ns">"http://myns.com/ns"</a>><b>text1</b><c>text2</c></a>', ARRAY[ARRAY['my','<a class="moz-txt-link-freetext" href="http://myns.com/ns">http://myns.com/ns</a>']]);<br> <br> </tt>kind regards, Arie Bikker<br> </body> </html>
From: Arie Bikker on 6 Jan 2010 17:46 Sorry for the previous NUUUB post, didn't now the mailing list doesn't support html ;( Robert Haas wrote: > On Tue, Jan 5, 2010 at 6:09 PM, Arie Bikker <arie(a)abikker.nl> wrote: > >> Hi all, >> >> Well I had to burn some midnight oil trying to figure out why a construct >> like >> SELECT xpath('name()','<a/>'); >> doesn't give the expected result. Kept getting an empty array: >> xpath >> ------------- >> {} >> instead of the expected "{a}" >> BugID 4294 and the TODO item "better handling of XPath data types" pointed >> in the right direction. >> whithin src/backend/utils/adt/xml.c in the function xpath the result of the >> call to xmlXPathCompiledEval is not handled optimally. In fact, the result >> is assumed to be a nodeset without consulting the ->type member of the >> result. I've made some minor changes to xml.c to handle some non-nodeset >> results of xmlXPathCompiledEval. >> Essentially, the revised code makes an array of all the nodes in the >> xpathobj result in case this is a nodeset, or an array with a single element >> in case the reult is a number/string/boolean. The problem cases mentioned in >> http://archives.postgresql.org/pgsql-hackers/2008-06/msg00616.php now work >> as expected. >> Revision of the code involves: >> - A switch statement to handle the result type of xmlXPathCompiledEval. >> - an additional function xmlpathobjtoxmltype. >> >> diff of the revisioned code with respect to original is in attached file. >> >> kind regards, Arie Bikker >> > > Hi, > > Could you please resend this as a context diff and add it to our patch > management application? > > http://wiki.postgresql.org/wiki/Submitting_a_Patch > https://commitfest.postgresql.org/action/commitfest_view/open > > Thanks! > > ...Robert > 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']]); kind regards, Arie Bikker
From: Scott Bailey on 6 Jan 2010 19:32 Arie Bikker wrote: > Sorry for the previous NUUUB post, didn't now the mailing list doesn't > support html ;( > Robert Haas wrote: >> On Tue, Jan 5, 2010 at 6:09 PM, Arie Bikker <arie(a)abikker.nl> wrote: >> >>> Hi all, >>> >>> Well I had to burn some midnight oil trying to figure out why a >>> construct >>> like >>> SELECT xpath('name()','<a/>'); >>> doesn't give the expected result. Kept getting an empty array: >>> xpath >>> ------------- >>> {} >>> instead of the expected "{a}" >>> BugID 4294 and the TODO item "better handling of XPath data types" >>> pointed >>> in the right direction. >>> whithin src/backend/utils/adt/xml.c in the function xpath the result >>> of the >>> call to xmlXPathCompiledEval is not handled optimally. In fact, the >>> result >>> is assumed to be a nodeset without consulting the ->type member of the >>> result. I've made some minor changes to xml.c to handle some non-nodeset >>> results of xmlXPathCompiledEval. >>> Essentially, the revised code makes an array of all the nodes in the >>> xpathobj result in case this is a nodeset, or an array with a single >>> element >>> in case the reult is a number/string/boolean. The problem cases >>> mentioned in >>> http://archives.postgresql.org/pgsql-hackers/2008-06/msg00616.php now >>> work >>> as expected. >>> Revision of the code involves: >>> - A switch statement to handle the result type of xmlXPathCompiledEval. >>> - an additional function xmlpathobjtoxmltype. >>> >>> diff of the revisioned code with respect to original is in attached >>> file. >>> >>> kind regards, Arie Bikker >>> >> >> Hi, >> >> Could you please resend this as a context diff and add it to our patch >> management application? >> >> http://wiki.postgresql.org/wiki/Submitting_a_Patch >> https://commitfest.postgresql.org/action/commitfest_view/open >> >> Thanks! >> >> ...Robert >> > 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']]); Awesome! This really helps. Scott -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
|
Next
|
Last
Pages: 1 2 3 Prev: [HACKERS] xpath improvement suggestion Next: [HACKERS] Auto-extending table partitions? |