Обсуждение: Bug #627:

Поиск
Список
Период
Сортировка

Bug #627:

От
pgsql-bugs@postgresql.org
Дата:
Harish Rao (rao.harish@acm.org) reports a bug with a severity of 4
The lower the number the more severe it is.

Short Description


Long Description
create table t1 (f1 real);
insert into t1 values(1.01);
select * from t1 where f1 > 1.01;


Sample Code
create table t1 (f1 real);
insert into t1 values(1.01);
select * from t1 where f1 > 1.01;


No file was uploaded with this report

Re: Bug #627:

От
Stephan Szabo
Дата:
On Fri, 29 Mar 2002 pgsql-bugs@postgresql.org wrote:

> Harish Rao (rao.harish@acm.org) reports a bug with a severity of 4
> The lower the number the more severe it is.
>
> Short Description
>
>
> Long Description
> create table t1 (f1 real);
> insert into t1 values(1.01);
> select * from t1 where f1 > 1.01;

What's the bug here?  An explanation would
be useful.

Re: Bug #627:

От
Tom Lane
Дата:
pgsql-bugs@postgresql.org writes:
> create table t1 (f1 real);
> insert into t1 values(1.01);
> select * from t1 where f1 > 1.01;

regression=# create table t1 (f1 real);
CREATE
regression=# insert into t1 values(1.01);
INSERT 139787 1
regression=# select * from t1 where f1 > 1.01;
 f1
----
(0 rows)

And your point was?

BTW, if you were going to complain that on your platform the SELECT
returns the row, don't bother.  Float comparisons are inherently
inaccurate.

You might, however, find that the behavior is less surprising if you do
the comparison against a float4 (== real) rather than float8 constant:

select * from t1 where f1 > '1.01'::real;

The query as you wrote it will convert the original 1.01 to float4
for storage and then to float8 for comparison against the second 1.01
(which never becomes float4), so a little bit of roundoff error is
likely to creep in.

            regards, tom lane