* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
Makes me curious if it really makes sense to keep trailing zeros...
AFAIR we consider them mainly as a display artifact. An application
that's declared a column as numeric(7,2) is likely to expect to see
exactly
On Wed, Aug 09, 2006 at 11:35:48PM -0400, Tom Lane wrote:
Stephen Frost [EMAIL PROTECTED] writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
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
On Thu, Aug 10, 2006 at 03:40:11AM -, Andrew - Supernews wrote:
On 2006-08-10, Stephen Frost [EMAIL PROTECTED] wrote:
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
Stephen Frost [EMAIL PROTECTED] writes:
This was using just a straight-up 'numeric' data type though. Perhaps
for that case we could drop the unnecessary zeros?
That would make numeric useless for the common scientific/engineering
usage where you write the number of decimal places you think
On Thu, Aug 10, 2006 at 09:20:09AM -0400, [EMAIL PROTECTED] wrote:
Mathematically, 1.0 = 0.9500... - 1.05000...
In theory, B-Tree could be fine with this. As long as the operators
for =, , , and are made to consistently understand this principle.
For example:
1.0 = 0.95
1.0 =
Brian C. DeRocher [EMAIL PROTECTED] writes:
It appears that when you create a view of a union, numeric data types
loose their scale and precision.
I think this is the same issue discussed here:
http://archives.postgresql.org/pgsql-hackers/2004-12/msg00408.php
That was just before 8.0 release,
* Tom Lane ([EMAIL PROTECTED]) wrote:
Brian C. DeRocher [EMAIL PROTECTED] writes:
It appears that when you create a view of a union, numeric data types
loose their scale and precision.
I think this is the same issue discussed here:
Stephen Frost [EMAIL PROTECTED] 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.
1.0
(3 rows)
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] 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
Stephen Frost [EMAIL PROTECTED] writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
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.
Nope,
On 2006-08-10, Stephen Frost [EMAIL PROTECTED] wrote:
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.
The comparison function must be
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
It could say not equal pretty reasonably as the scale is
different.
Nope, there are exactly three options: equal, less, greater.
btree doesn't understand anything else.
Ah, yeah, I can see how something else
Stephen Frost [EMAIL PROTECTED] writes:
Makes me curious if it really makes sense to keep trailing zeros...
AFAIR we consider them mainly as a display artifact. An application
that's declared a column as numeric(7,2) is likely to expect to see
exactly two digits after the decimal point.
13 matches
Mail list logo
