dbTalk Databases Forums  

[BUGS] Unexpected behaviour of numeric datatype when mixed with,float4,

mailing.database.pgsql-bugs mailing.database.pgsql-bugs


Discuss [BUGS] Unexpected behaviour of numeric datatype when mixed with,float4, in the mailing.database.pgsql-bugs forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Ezequiel Tolnay
 
Posts: n/a

Default [BUGS] Unexpected behaviour of numeric datatype when mixed with,float4, - 04-10-2005 , 02:25 PM






I found an odd behaviour, which I believe it is a bug, and for us it is
a serious matter. Can anyone on a platform or version other than
PostgreSQL 8.0.1 on Windows XP Advanced Server check if you can
reproduce the finding on your server?

Tables with columns specified as numeric using a domain type seem to be
capable of containing values with a higher precision than specified,
when mixing in operations with float4 (which we use to store percentages).

The following snippet can be used to reproduce the error (run each step
sequencially and observe results):

--step 1: direct execution on base type
SELECT 92::numeric(15,4) * 0.2::float4;

--step 2: using a function variable and a domain
CREATE DOMAIN currency AS numeric(15,4);
CREATE TABLE test (id serial, amt currency);
CREATE FUNCTION f_test(currency) RETURNS currency AS $$
DECLARE n currency;
BEGIN n := $1 * 0.2::float4;
INSERT INTO test (amt) VALUES (n); RETURN n;
END $$ LANGUAGE PLPGSQL;
SELECT f_test(92);

--step 3: wrong precision stored in the table!
SELECT id, amt, amt::currency as amt_still_bad,
amt::numeric(15,4) as amt_casted_as_base,
amt::float::currency as amt_casted_back_n_forth
FROM test;

Thanks folks.

Ezequiel Tolnay
Good Business Technology
Sydney, NSW, Australia

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Reply With Quote
  #2  
Old   
Ezequiel Tolnay
 
Posts: n/a

Default Re: [BUGS] Unexpected behaviour of numeric datatype when mixed with,float4, - 04-10-2005 , 07:52 PM






Tom Lane wrote:

Quote:
Ezequiel Tolnay <mail (AT) etolnay (DOT) com.ar> writes:


CREATE DOMAIN currency AS numeric(15,4);
CREATE TABLE test (id serial, amt currency);
CREATE FUNCTION f_test(currency) RETURNS currency AS $$
DECLARE n currency;
BEGIN n := $1 * 0.2::float4;
INSERT INTO test (amt) VALUES (n); RETURN n;
END $$ LANGUAGE PLPGSQL;



plpgsql doesn't currently enforce domain constraints, so the assignment
to n isn't doing the rounding that you expect. Until someone gets
around to fixing that, an explicit coercion is probably what you need:

n := cast($1 * 0.2::float4 AS currency);



Please note that the critical issue is a column defined as numeric(15,4)
(through the domain alias), but still capable of containing numbers with
higher precision. I wonder how is it possible to store a numeric with
higher precision on a column where the precision is clearly defined. Are
the numeric values stored on a column always variable precision, and the
precision being only enforced on assignment? Wouldn't this impact
heavily in performance and disk space usage?
In any case, it looks like the only flaw is when inserting or updating
with a plpgsql variable into a column defined as a domain for a fixed
precision numeric.

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo (AT) postgresql (DOT) org)


Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.