From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | eugeny(at)zhuzhnev(dot)com, pgsql-bugs <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 21:54:50 |
Message-ID: | 2053300.1679608490@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
> On 23 Mar 2023, at 19:31, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I wonder if we should rethink that and have these operations strip
>> insignificant trailing zeroes.
> Any app relying on insignificant trailing zeroes seems broken, but the inverse
> can be argued as well. It's however quite easy to argue for the stripped
> output being more readable though.
It's more readable for sure, and it duplicates what you got in pre-v14
versions, at least textually. I'm not sure I'd propose back-patching
this, but it feels like a good idea for HEAD.
The argument for the current behavior probably goes like "we're exposing
the actual precision of the value". But I don't believe that we are;
we're exposing the maximum possible precision. We have no way to know
how precise the original timestamp or interval input was. So I don't
think there's much basis for claiming that the result is good to six
fractional digits.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2023-03-23 22:00:24 | Re: BUG #17866: behavior does not match documentation |
Previous Message | Daniel Gustafsson | 2023-03-23 21:25:49 | Re: BUG #17866: behavior does not match documentation |