| 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
| 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 |