From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Bryn Llewellyn <bryn@yugabyte.com>
Cc: pgsql-hackers list <pgsql-hackers@lists.postgresql.org>
Subject: Re: Have I found an interval arithmetic bug?
Date: Wed, 28 Jul 2021 13:05:44 -0400
Message-ID: <593114.1627491944@sss.pgh.pa.us> (raw)
In-Reply-To: <CA+TgmoZbuxd=+oLHAB5iZVA3yGkyfkJXhqS4E1vGe9QcK3BE3A@mail.gmail.com>
References: <BDAE4B56-3337-45A2-AC8A-30593849D6C0@yugabyte.com>
<20210402180549.GF9270@momjian.us>
<CALNJ-vRJUo62KNrQsiSsNAuPSBYpOXk8SPLh6r5jwHVzYai=HA@mail.gmail.com>
<20210402234943.GB29126@momjian.us>
<95D98B9E-CD54-4FAC-9574-D950E9741CAC@yugabyte.com>
<20210403010229.GE29126@momjian.us>
<20210727193614.GE19774@momjian.us>
<456756.1627416114@sss.pgh.pa.us>
<CA+Tgmob-eV1wUY5zVpzPVFo1-jtuTsn1BJ5OMKQp4bc1a7=Ohw@mail.gmail.com>
<588727.1627487554@sss.pgh.pa.us>
<CA+TgmoZbuxd=+oLHAB5iZVA3yGkyfkJXhqS4E1vGe9QcK3BE3A@mail.gmail.com>
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Jul 28, 2021 at 11:52 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> You know, I was thinking exactly that thing earlier. Changing the
>> on-disk representation is certainly a nonstarter, but the problem
>> here stems from expecting interval_in to do something sane with inputs
>> that do not correspond to any representable value. I do not think we
>> have any other datatypes where we expect the input function to make
>> choices like that.
> A case that is perhaps more theoretically similar to the instance at
> hand is rounding during the construction of floating point values. My
> system thinks '1.00000000000000000000000001'::float = '1'::float, so
> in that case, as in this one, we've decided that it's OK to build an
> inexact representation of the input value.
Fair point, but you decided when you chose to use float that you don't
care about the differences between numbers that only differ at the
seventeenth or so decimal place. (Maybe, if you don't understand what
float is, you didn't make that choice intentionally ... but that's
a documentation issue not a code shortcoming.) However, it's fairly
hard to believe that somebody who writes '1.4 years'::interval doesn't
care about the 0.4 year. The fact that we silently convert that to,
effectively, 1.33333333... years seems like a bigger roundoff error
than one would expect.
> I am dubious that it's worth the pain of making the input function
> reject cases involving fractional units. It's true that some people
> here aren't happy with the current behavior, but they may no happier
> if we reject those cases with an error, and other people may then be
> unhappy too.
Maybe. A possible compromise is to accept only exactly-representable
fractions. Then, for instance, we'd take 1.5 years (resulting in 18
months) but not 1.4 years. Now, this might fall foul of your point about
not wanting to mislead people into expecting the system to do things it
can't; but I'd argue that the existing behavior misleads them much more.
> I think your previous idea was the best one so far: fix
> the input function so that 'X years Y months' and 'Y months X years'
> always produce the same answer, and call it good.
That would clearly be a bug fix. I'm just troubled that there are
still behaviors that people will see as bugs.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, robertmhaas@gmail.com, bruce@momjian.us, bryn@yugabyte.com, pgsql-hackers@lists.postgresql.org
Subject: Re: Have I found an interval arithmetic bug?
In-Reply-To: <593114.1627491944@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox