Re: Using regoper type with OPERATOR()
От | Tony Theodore |
---|---|
Тема | Re: Using regoper type with OPERATOR() |
Дата | |
Msg-id | CAJFv53qPHQ1ZZ6=j7d_6bnxrEwfwQkoMHgUw7wOwPTj8M_Wfgg@mail.gmail.com обсуждение исходный текст |
Ответ на | Using regoper type with OPERATOR() (Tony Theodore <tony.theodore@gmail.com>) |
Ответы |
Re: Using regoper type with OPERATOR()
|
Список | pgsql-novice |
On 7 October 2011 06:33, Gavin Flower <GavinFlower@archidevsys.co.nz> wrote: > > Glad to be of help! > > There is often a tradeoff between flexibility and performance. > > What you tried to do looks pretty neat. > > Would writing something in C give you sufficient flexibility with reasonable > performance? Possibly, but I wouldn't know where to start. I just did some more testing, and the most performant solution is to just have both columns (fraction and amount) default them to 1 and 0 respectively, then just calculate (price * fraction + amount). > However, in a production system, and in an environment where most people do > not have a range of skills in depth, it is better to keep things simple - to > ease ongoing maintenance. Sometimes super smart code is a liability, as > mere mortals can not maintain it. I have been guilty of this crime! > > I guess a good rule of thumb, is imagine that you are called back in 2 years > to fix, or modify your code - how would you feel: still proud of what you > did, or wonder what you were thinking at the time (or both!)? > > Somes a bit of complexity is necessar, and can save a lot of code, or imply > be the most practical way of doing something. I was trying to build some flexibility in so that I wouldn't need to revisit this in the future :) Down the track, I'll investigate operator/function lookups further, but I'll keep it simple for the time being. BTW, is novice the right list for questions like these? > Note that one of the points I was trying to make is to avoid float type data > types for money. In COBOL we used integers to hold the number of cents, so > add&subtract operations were not subject to rounding, in pg you can use the > money type. Thanks for the tip, this is mostly an analysis database, so rounding won't be an issue. Cheers, Tony
В списке pgsql-novice по дате отправления: