Re: [BUGS] numerics lose scale and precision in views of unions - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: [BUGS] numerics lose scale and precision in views of unions
Date
Msg-id 20060810022215.GP20016@kenobi.snowman.net
Whole thread Raw
In response to Re: [BUGS] numerics lose scale and precision in views of unions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [BUGS] numerics lose scale and precision in views of unions
List pgsql-hackers
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > Sounds good to me.  I'd like to talk a bit about the expected behavior
> > of a numeric hash function.  This is the current behavior:
>
> You're hijacking the thread, tsk tsk.

Yeah, but Brian sits across the hall from me at work... :)

> Yeah, because numeric_cmp says that 1.0 and 1.00 are equal (what else
> could it say?  "less" and "greater" are surely wrong).  So you need to

It could say "not equal" pretty reasonably as the scale is
different.  With all due respect, it seems to me that we track the scale
for the very reason that it may be different for different numbers.
Unless the SQL spec says differently or we get complaints from people
I'm all for keeping the current semantics though.

> ensure that dscale is not included in the hash calculation.  The
> comments in numeric.h claim that you should not need to worry about
> leading or trailing zeroes, but it sounds like you do need to worry
> about differing weights for zero.  Might be easiest and safest to use
> only nonzero digit words in the hash calculation.

Makes sense to me.
Thanks!
    Stephen

pgsql-hackers by date:

Previous
From: Satoshi Nagayasu
Date:
Subject: Re: [PATCHES] pgstattuple extension for indexes
Next
From: Bruce Momjian
Date:
Subject: Re: [COMMITTERS] pgsql: Move "#define inline __inline"