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
