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
