Wouldn't (4,3) let me store 0.000 through 9.999? Maybe I'm still not
following what both numbers mean.
I understand the point about states/counties with 3 decimal digits of
sales tax, so I'd probably want to do (5,5) which should give me
0.00000 - 0.99999, and store 9.825% sales tax as .09825. I'm
suggesting storing sales tax as a number between 0 and 1 so I can
easily multiply it against a subtotal to get the tax amount, storing
anything over 1.0 is unnecessary.
Also, if you just say "numeric" (without any numbers) then Postgres
lets you store any number you wish and will never do any rounding of
any sort, correct? If there a price you pay for this in terms of
perf, bytes on disk, etc?
Another idea is if I'm tying myself down to a certain level of decimal
accuracy in the first place, why not just store everything as an Int2?
9.825% would be stored as 9825 and I'll divide everything by 100000
when I calc sales tax. If I'm not mistaken, integral data types are
faster for Postgres and less bytes on disk, right? BTW, I will never
be doing any math using Postgres, it's just for pure storage..
Mike
On Thu, Oct 8, 2009 at 5:23 PM, Rich Shepard <rshepard@appl-ecosys.com> wrote:
> On Thu, 8 Oct 2009, Mike Christensen wrote:
>
>> I'll probably just use 3,3 and store this value between 0 and 1, since all
>> I'll be doing with this number is using it to multiply against a subtotal.
>> 3,3 gives me 0.000 through 0.999, correct?
>
> Mike,
>
> No. The two digits represent the width of the column and the number of
> significant digits. Try (4,3).
>
> Rich
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>