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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general > -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
