> On 27/3/13 at 9:12 AM, Steve Crawford wrote:
>> Thoughts? Is this the "no surprises" way that money input should behave?
I took a quick look at cash_in(), which is what's being complained of
here (not really casting). There are several things that seem like
they could possibly stand to be tightened up:
1. it allows parens to indicate "negative", eg (1234.56), but it's not
very anal about insisting that a paren appear on the right iff there's
one on the left, nor about the exact position of the trailing paren.
2. it allows thousands separators to the right of the decimal point,
but only as long as it's still looking for digits, viz:
regression=# select '123.4567'::money;
money
---------
$123.46
(1 row)
regression=# select '123.45,67'::money;
money
---------
$123.46
(1 row)
regression=# select '123.456,7'::money;
ERROR: invalid input syntax for type money: "123.456,7"
LINE 1: select '123.456,7'::money;
^
3. it is not picky about where you put thousands separators to the left
of the decimal point.
Of these I think #2 is a flat-out bug: the digit collection loop should
reject thousands seps once it's found a decimal point. #1 is a shortcut
acknowledged in the code comments, and while it probably is worth
fixing, I'm finding it hard to get really excited about it. I think the
debatable point is whether we want to tighten up #3 and if so how much.
We surely do not want to insist that thousands separators are required.
I think that different locales may space them differently --- at least,
cash_out treats the spacing as configurable --- but do we want to
zreject, say, commas every three places if the locale specifies four?
I think that might be a little too picky. On the whole I'm okay with
treating them as noise as long as they're to the left of the decimal.
Gavan Schneider <pg-gts@xxxxxxxxxxx> writes:
> I would defer to a CPA on the correct conventions for rounding.
> However I have a vague notion there are circumstances when
> rounding is always up, always down and (only sometimes) to the
> nearest. If the money type is meant to be serious then these
> conventions need to be followed/settable on a column by column
> basis. And money is done in whole dollars, thousands of dollars,
> and fractional cents according to the situation, i.e., not just
> two decimal places... another setting.
If you need that kind of control over rounding you need to be doing it
in your calculation code. Expecting an I/O function to provide it
is doomed to failure.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
