In contrast to certain other open-source databases, PostgreSQL leans
toward protecting data from surprises and erroneous input, i.e.
rejecting a date of 2013-02-31 instead of arbitrarily assigning a date
of 2013-03-03. Similar "throw error" instead of "take a guess"
philosophy applies to numeric and string operations as well. It's an
approach I appreciate.
But it appears that the philosophy does not extend to the "money" type.
Although there are certain checks including no alpha, '$' and '-', if
present, must be in the first two characters of the string and commas
can't be at the end. Otherwise the casting is fairly liberal. Commas,
for instance, can appear nearly anywhere including after the decimal point:
select ',123,456,,7,8.1,0,9'::money;
money
----------------
$12,345,678.11
Somewhat more worrisome is the fact that it automatically rounds input
(away from zero) to fit.
select '123.456789'::money;
money
---------
$123.46
select '$-123.456789'::money;
money
----------
-$123.46
Thoughts? Is this the "no surprises" way that money input should behave?
Cheers,
Steve
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
