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

> 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.


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Reply via email to