| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | 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 13:08:25 |
| Message-ID: | 13185.1485522505@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Greg Stark <stark(at)mit(dot)edu> writes:
> On 24 January 2017 at 03:42, Peter van Hardenberg <pvh(at)pvh(dot)ca> wrote:
>> The basic concept is that the value of a currency type is that it would
>> allow you to operate in multiple currencies without accidentally adding
>> them. You'd flatten them to a single type if when and how you wanted for any
>> given operation but could work without fear of losing information.
> I don't think this even needs to be tied to currencies. I've often
> thought this would be generally useful for any value with units.
There already is an extension somewhere for attaching units to numeric
values, which would be a place to start from for this purpose. The
things I think are unique to the currency situation are:
* Time-varying conversion ratios.
* Conventional number of decimal places for any given currency.
* Idiosyncratic I/O formats (symbol to left or right of number,
odd rules for negatives, etc). I think the space here is covered
by the POSIX currency locale rules.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-01-27 13:13:33 | Re: pg_ls_dir & friends still have a hard-coded superuser check |
| Previous Message | Dave Page | 2017-01-27 13:05:48 | Re: pg_ls_dir & friends still have a hard-coded superuser check |