Re: [PATCH] Normalize numeric/bigint scientific notation after rounding

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: 韩建桥 <hanjianqiao(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] Normalize numeric/bigint scientific notation after rounding
Date: 2026-11-13 18:28:27
Message-ID: 521760.1794594507@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

=?UTF-8?B?6Z+p5bu65qGl?= <hanjianqiao(at)gmail(dot)com> writes:
> While working with PG, I found that to_char returns value that is
> right but the format is wrong:
> SELECT to_char(999::numeric, '9.9EEEE');
> Result is: 10.0e+02, and I think the expected output should be: 1.0e+03.
> With help from ChatGPT, I figured that get_str_from_var_sci()
> determines the exponent
> before rounding the significand. If rounding increases the
> significand's absolute value to
> 10, the original exponent is still used. The attached patch adds a
> check for this,and adjusts
> the significand and the exponent.

Good point. The patch feels a little brute-force, but I don't see
a simple way to do better, and it's probably not worth a huge
amount of trouble to make this edge case faster.

Is there any case in which we have the reverse problem, ie rounding
down causes the leading digit to become 0?

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Antonin Houska 2026-11-13 18:35:15 Re: Allow progress tracking of sub-commands
Previous Message Antonin Houska 2026-11-13 18:18:59 Re: Allow progress tracking of sub-commands