Re: Unexpected behaviour of numeric datatype when mixed with,float4,
От | Ezequiel Tolnay |
---|---|
Тема | Re: Unexpected behaviour of numeric datatype when mixed with,float4, |
Дата | |
Msg-id | 4259C31B.3080700@etolnay.com.ar обсуждение исходный текст |
Ответ на | Re: Unexpected behaviour of numeric datatype when mixed with,float4, domains and plpgsql variables (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
Tom Lane wrote: >Ezequiel Tolnay <mail@etolnay.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.
В списке pgsql-bugs по дате отправления: