Re: BUG #17866: behavior does not match documentation

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

In response to

Responses

Browse pgsql-bugs by date

  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