Re: BUG #17866: behavior does not match documentation

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

In response to

Responses

Browse pgsql-bugs by date

  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