machine-dependent hash_any vs the regression tests

So the proposed changes in hash_any make its hash values different
between big-endian and little-endian machines (at least for string keys;
for keys that are really arrays of int, I think the changes will
unify the behavior). This means that the hash_seq_search traversal
order for an internal hash table changes, and it turns out this breaks
at least two regression tests: portals and dblink. The portals test
is easy to fix by adding a couple of ORDER BYs, but the problem with
dblink is here:

SELECT dblink_get_connections();
dblink_get_connections
------------------------
! {dtest1,dtest2,dtest3}
(1 row)

SELECT dblink_is_busy('dtest1');
--- 714,720 ----
SELECT dblink_get_connections();
dblink_get_connections
------------------------
! {dtest1,dtest3,dtest2}
(1 row)

SELECT dblink_is_busy('dtest1');

and right offhand I can't think of a simple way to force those array
elements into a consistent order.

No doubt that can be worked around, but does anyone wish to argue that
this whole thing is a bad path to be headed down? We're not going to
gain a *whole* lot of speedup from the word-wide-hashing change, and
so maybe this type of headache isn't worth the trouble.

regards, tom lane