Neil Conway <neilc(at)samurai(dot)com> writes:
> For any two numerics that compare equal, we need to compute the same
> hash value for both datums, even if their bit patterns differ.
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?
There are various related cases involving unstripped leading zeroes.
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
Lastly, calling hashint2 seems like overkill, you might as well
just XOR the weight into the digit_hash.
regards, tom lane
In response to
pgsql-patches by date
|Next:||From: Heikki Linnakangas||Date: 2007-04-27 08:44:16|
|Subject: Re: [BUGS] BUG #3245: PANIC: failed to re-find shared lock object|
|Previous:||From: Simon Riggs||Date: 2007-04-27 08:05:38|
|Subject: Re: [PATCHES] Reviewers Guide to DeferredTransactions/TransactionGuarantee|