From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | "Brian C(dot) DeRocher" <brian(dot)derocher(at)mitretek(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [BUGS] numerics lose scale and precision in views of unions |
Date: | 2006-08-10 00:12:17 |
Message-ID: | 2361.1155168737@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)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.
> abc=# select * from test1;
> a1
> --------
> 1.00
> 1.0000
> 1.0
> (3 rows)
> abc=# select * from test1 group by a1;
> a1
> ------
> 1.00
> (1 row)
> abc=# select distinct a1 from test1;
> a1
> ------
> 1.00
> (1 row)
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
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2006-08-10 02:22:15 | Re: [BUGS] numerics lose scale and precision in views of unions |
Previous Message | Stephen Frost | 2006-08-09 23:48:04 | Re: [BUGS] numerics lose scale and precision in views of unions |
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Saito | 2006-08-10 01:04:04 | Re: [GENERAL] WIN32 Build? |
Previous Message | andrew | 2006-08-10 00:11:36 | Re: Buildfarm failure on ecpg/test/pgtypeslib |