Comment 6 for bug 797304

Yes, it's surprising and concerning. It's what I thought I saw. (And yes, as the bug report says at the very top, we're on 9.0).

However, your test returns a/b/c in the expected order. But of course there are probably no 245 fields where subfields c or b come before a, so to also remove the hypothesis that ordering may somehow be alphabetic based on the matching attribute name, a better test is:

select (oils_xpath('//*[@tag="245"]/*[@code="b"]/text()|//*[@tag="245"]/*[@code="c"]/text()|//*[@tag="245"]/*[@code="a"]/text()',
'<marc><data tag="245"><sub code="c">foo</sub><sub code="a">bar</sub><sub code="b">baz</sub></data></marc>'));

This returns:

  oils_xpath
---------------
 {foo,bar,baz}
(1 row)

... suggesting that you're right, it is document node order and thus compliant with XPath 2.0.

So we can put that as a notch in our collective wisdom about oils_xpath() / the native XPATH() function on which it is based, and at some point turn our attention to other areas where it may be a problem. Thanks for the clarification.

Now, back to the problem at hand: I believe my branch does fix the problem reported here (along with the problem reported in 797307). Your approach looks like it would solve this problem and may be more efficient, but I honestly don't know how the cost of invoking oils_xpath() multiple times compares to iterating through the contents of the array and doing comparisons on the array contents against uri_href (and I don't know whether there would be any performance difference between 9.0 and 8.4).