On Tue, Jan 5, 2010 at 6:09 PM, Arie Bikker <arie@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