On 7 October 2011 06:33, Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)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
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
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.
In response to
pgsql-novice by date
|Next:||From: Gavin Flower||Date: 2011-10-09 21:03:52|
|Subject: Re: Using regoper type with OPERATOR()|
|Previous:||From: Henry Drexler||Date: 2011-10-07 16:33:12|
|Subject: Re: opposite of chr(int)|