On Tue, Jan 5, 2010 at 6:09 PM, Arie Bikker <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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers