The hash opclasses for time, timestamptz, timestamp use the hashfloat8() hash function even when we are using integer datetimes. I had been aware of this for awhile but thought it was just harmless ugliness ... so long as you get a hash value, who cares how it was computed? But on second thought, this means that almost any arbitrary bitpattern can be fed to hashfloat8(), and in particular an IEEE signaling NAN could be fed to it, possibly resulting in an unexpected error. (I tried this on my Linux box and didn't get an error, possibly because the only float operation actually performed is a non-NaN-aware comparison; but perhaps other platforms would show the failure.)
Meanwhile, timetz_hash and interval_hash have the opposite problem: they use plain ol' hash_any for structs that might contain either float8 or int8. That works fine for integer datetimes but would give different hash codes for positive and negative float zeroes. I'm not certain how to get the datetime code to compute a negative float zero, but I wouldn't swear it can't be done, either. Since we've already broken hash index compatibility for 8.3, this seems like a good time to clean this up. Barring objections, I will make physically separate hash functions for each of these datatypes and give them two appropriate code paths depending on #ifdef HAVE_INT64_TIMESTAMP. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org