Hi,
Can someone explain why postgres complains in this case:
create table t(d real, check(d=0.00603));
insert into t values (0.00603);
ERROR: new row for relation t violates check constraint t_d_check
thanks
Jacek
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
Jacek Becla wrote:
create table t(d real, check(d=0.00603));
insert into t values (0.00603);
ERROR: new row for relation t violates check constraint t_d_check
Because equality is not well-defined for real values?
- Jeremy
--
Sent via pgsql-general mailing list
On Mar 23, 2009, at 1:41 PM, Jeremy Harris wrote:
Because equality is not well-defined for real values?
That was my first thought, too, but why would two identical real
literals evaluate to different bit patterns?
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To
On Mar 23, 2009, at 2:54 PM, Jacek Becla wrote:
Hi,
Can someone explain why postgres complains in this case:
create table t(d real, check(d=0.00603));
insert into t values (0.00603);
ERROR: new row for relation t violates check constraint t_d_check
thanks
Jacek
try this:
insert into t
On Mon, Mar 23, 2009 at 1:54 PM, Jacek Becla be...@slac.stanford.edu wrote:
Hi,
Can someone explain why postgres complains in this case:
create table t(d real, check(d=0.00603));
insert into t values (0.00603);
ERROR: new row for relation t violates check constraint t_d_check
Without any
Thanks Ries. Do you know if that is a postgres feature or a bug?
In practice, I wanted to load the data from a file using
COPY FROM. Modifying a large csv file in impractical and
not very elegant.
thanks,
Jacek
ries van Twisk wrote:
On Mar 23, 2009, at 2:54 PM, Jacek Becla wrote:
Hi,
On Mon, Mar 23, 2009 at 2:52 PM, Jacek Becla be...@slac.stanford.edu wrote:
Thanks Ries. Do you know if that is a postgres feature or a bug?
It's not a bug, it's lack of precision in the definition on your part
being interpreted by pgsql. When you create the table, you get this:
create table
Scott Marlowe scott.marl...@gmail.com writes:
You can either cast the check constraint, or change the field type to
match double precision.
The short answer here is that 0.00603::double precision and
0.00603::real are unlikely to be exactly the same value, and
which one is greater is a matter
