| From: | Brad DeJong <Brad(dot)Dejong(at)infor(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <stark(at)mit(dot)edu> |
| Cc: | Peter van Hardenberg <pvh(at)pvh(dot)ca>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Thom Brown <thom(at)linux(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com> |
| Subject: | Re: GSoC 2017 |
| Date: | 2017-01-27 14:17:10 |
| Message-ID: | CY1PR0201MB1897A4658BED15744EF40488FF760@CY1PR0201MB1897.namprd02.prod.outlook.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On January 27, 2017 07:08, Tom Lane wrote:
> ... The things I think are unique to the currency situation are: ...
Add the potential for regulatory requirements to change at any time - sort of like timezone information. So no hard coded behavior.
rounding method/accuracy
storage precision different than display precision
conversion method (multiply, divide, triangulate, other)
use of spot rates (multiple rate sources) rather than/in addition to time-varying rates
responding to the overall idea of a currency type
Numeric values with units so that you get a warning/error when you mix different units in calculations? Ability to specify rounding methods and intermediate precisions for calculations?
+1 Good ideas with lots of potential applications.
Built-in currency type?
-1 I suspect this is one of those things that seems like a good idea but really isn't.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-01-27 14:35:44 | Re: pg_ls_dir & friends still have a hard-coded superuser check |
| Previous Message | Peter Eisentraut | 2017-01-27 14:14:59 | Re: pg_background contrib module proposal |