Re: [HACKERS] GSoC 2017
| От | Peter van Hardenberg |
|---|---|
| Тема | Re: [HACKERS] GSoC 2017 |
| Дата | |
| Msg-id | CABTbUphCdQdSB6vsgrNiE9mh2x3D8iGGzhbemoX17ZffTEEM6g@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] GSoC 2017 (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
| Ответы |
Re: [HACKERS] GSoC 2017
|
| Список | pgsql-hackers |
On Mon, Jan 23, 2017 at 4:12 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
- On 1/23/17 3:45 PM, Peter van Hardenberg wrote:A new currency type would be nice, and if kept small in scope, might be
manageable.
I'd be rather nervous about this. My impression of community consensus on this is a currency type that doesn't somehow support conversion between different currencies is pretty useless, and supporting conversions opens a 55 gallon drum of worms. I could certainly be mistaken in my impression, but I think there'd need to be some kind of consensus on what a currency type should do before putting that up for GSoC.
There's a relatively simple solution to the currency conversion problem which avoids running afoul of the various mistakes some previous implementations have made. Track currencies separately and always ask for a conversion chart at operation time.
Let the user specify the values they want at conversion time. That looks like this:
=> select '1 CAD'::currency + '1 USD'::currency + '1 CHF'::currency
'1.00CAD 1.00USD 1.00CHF'
=> select convert('10.00CAD'::new_
12.50USD
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 have no opinion about the most pleasing notation for the currency conversion chart, but I imagine it would be reasonable to let users provide a default set of conversion values somewhere.
There are interesting and worthwhile conversations to have about non-decimal currencies, but I think it would be totally reasonable not to support them at all in a first release. As for currency precision, I would probably consider leaning on numeric under the hood for the actual currency values themselves but IANAA (though I have done quite a lot of work on billing systems).
If it would be helpful, I could provide a detailed proposal on the wiki for others to critique?
Peter van Hardenberg
San Francisco, California
"Everything was beautiful, and nothing hurt."—Kurt Vonnegut
San Francisco, California
"Everything was beautiful, and nothing hurt."—Kurt Vonnegut
В списке pgsql-hackers по дате отправления: