On Wed, Sep 7, 2011 at 23:48, Tom Lane wrote:
> Also, the way yours is set up, I'm dubious that it
> does the right thing when the last '0' specifier is to the left of the
> decimal point.
When the last '0' is left of the decimal point, Num->zero_end is set
to 0, so the branch dealing with that i
Marti Raudsepp writes:
> On Wed, Sep 7, 2011 at 21:37, Tom Lane wrote:
>> Hmm. I agree that this is a bug, but the proposed fix seems like a bit
>> of a kluge. Wouldn't it be better to make get_last_relevant_decnum
>> honor its contract, that is not delete any relevant digits?
> You're right, it
On Wed, Sep 7, 2011 at 21:37, Tom Lane wrote:
> Hmm. I agree that this is a bug, but the proposed fix seems like a bit
> of a kluge. Wouldn't it be better to make get_last_relevant_decnum
> honor its contract, that is not delete any relevant digits?
You're right, it was a kludge.
Here's an impr
Marti Raudsepp writes:
> This patch fixes an edge case bug in the numeric to_char() function.
> When the numeric to_char format used fillmode (FM), didn't contain 0s
> and had a trailing dot, the integer part of the number was truncated in
> error.
> to_char(10, 'FM99.') used to return '1', afte
Hi,
This patch fixes an edge case bug in the numeric to_char() function.
When the numeric to_char format used fillmode (FM), didn't contain 0s
and had a trailing dot, the integer part of the number was truncated in
error.
to_char(10, 'FM99.') used to return '1', after this patch it will return '
