From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | eugeny(at)zhuzhnev(dot)com |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Subject: | Re: BUG #17866: behavior does not match documentation |
Date: | 2023-03-23 18:31:35 |
Message-ID: | 1944674.1679596295@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> pgc=# SELECT EXTRACT(EPOCH FROM INTERVAL '5 days 3 hours');
> extract
> ---------------
> 442800.000000
> (1 row)
> But in documentation we can see:
> SELECT EXTRACT(EPOCH FROM INTERVAL '5 days 3 hours');
> Result: 442800
Hmm. That's not wrong exactly, but it's fair to question whether it
satisfies the POLA. This behavior change happened with commit a2da77cdb
(Change return type of EXTRACT to numeric), and it was intentional
according to the commit log:
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
But exactly nothing was mentioned of that in user-facing docs.
I wonder if we should rethink that and have these operations strip
insignificant trailing zeroes. It looks like that could be done as
practically a one-liner change, since int64_div_fast_to_numeric isn't
yet used anywhere except in these datetime extraction functions.
(The test cases that change behavior are either reverting to their
pre-a2da77cdb output, or were newly added in that commit.)
Thoughts?
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
strip-trailing-zeroes-in-datetime-extract.patch | text/x-diff | 34.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2023-03-23 21:25:49 | Re: BUG #17866: behavior does not match documentation |
Previous Message | Tom Lane | 2023-03-23 15:52:05 | Re: An update deadlock bug |