Re: BUG #17866: behavior does not match documentation
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: eugeny@zhuzhnev.com
Cc: pgsql-bugs@lists.postgresql.org,
Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Date: 2023-03-23T18:31:35Z
Lists: pgsql-bugs
Attachments
- strip-trailing-zeroes-in-datetime-extract.patch (text/x-diff) patch
PG Bug reporting form <noreply@postgresql.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
Commits
-
Doc: adjust examples of EXTRACT() output to match current reality.
- fbbd7edca867 16.0 landed
- 707691ea620e 15.3 landed
- 07a9f4f73386 14.8 landed
-
Change return type of EXTRACT to numeric
- a2da77cdb466 14.0 cited