On Fri, 2007-04-27 at 04:09 -0400, Tom Lane wrote:
> I feel uncomfortable about this proposal because it will compute
> different hashes for values that differ only in having different
> numbers of trailing zeroes. Now the numeric.c code is supposed to
> suppress extra trailing zeroes on output, but that's never been a
> correctness property ... are we willing to make it one?
I don't think that is such an onerous requirement: we could easily add
code to enforce this invariant (that might even be worth doing
regardless, to verify that the comments remain consistent with reality).
> There are various related cases involving unstripped leading zeroes.
numeric.h claims that leading zeros will also be stripped -- is that not
correct?
> Another point is that sign = NUMERIC_NAN makes it a NAN regardless
> of any other fields; ignoring the sign does not get the right result
> here.
I believe the patch was actually correct for NUMERIC_NAN (it already
special-cased it).
On Fri, 2007-04-27 at 10:02 -0400, Tom Lane wrote:
> Something else I just remembered is that ndigits = 0 makes it a zero
> regardless of the weight.
Good point, fixed.
> > Perhaps a sufficiently robust way would be to form the hash as the
> > XOR of each supplied digit, circular-shifted by say 3 times the
> > digit's weight.
-Neil