Well, this may be a good enhancement request, add something like
d=decimal point, supressed if alone.
Yeah. Maybe that's all that need to be said. :)
> In particular, one might reasonably choose a format string like 'FM999,999D99' and not realize it will fail on whole numbers. Is there any particular reason the D is not suppressible in this case, either by default or as an option? It seems to me if the trailing 0s are suppressed, the decimal should follow suit for whole numbers.
It does not fail, it just works in a diffrent way of what you would
like. Regarding supression, IMO it's a bad thing, it can lead to
misleading results. Imagine it is, and you do a right aligned print (
usual for numbers ) of prices 5.45, 1.20, 99.00, 2.40, and you end up
with ( using x for align )
price:
------
xx5.45
xx1.20
xxxx99
xx2.40
It would be misleading, I prefer to have xxx99., ugly but clearer IMO
( of course one never supress decimals in prices, so I would use
990D00, but anyway ).
Francisco Olarte.
I appreciate the comment and explanation. But your example shows numbers where the trailing 0s are not suppressed. It seems to me that if you're requesting suppression of trailing 0s, then you're accepting that your numbers aren't going to align in the first place. And so it's hard for me to see how, for example "99." is ever going to be desirable output if suppression is what you're after.
And just as context on my end, the times I use to_char are generally to merge numbers into a document or some fragment of English text. For anything going into a table, I'd usually just leave it as a number and case it to the desired (fixed) number of decimals. And as we've touched on, it may just be different use cases colliding! :)
Cheers,
Ken
--
![]()
AGENCY Software
A Free Software data system
By and for non-profits
(253) 245-3801
learn more about AGENCY or
follow the discussion.
