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
>
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 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
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
> >
* 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
>
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.
> Ei
* 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 someth
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 func
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
> differ
* 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 hal
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
>
* 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:
> http://archives.postgresql.org/pgsql-hackers/2
"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 rele
13 matches
Mail list logo
