From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Bruce Momjian <bruce@momjian.us>, Bryn Llewellyn <bryn@yugabyte.com>,
        pgsql-hackers list <pgsql-hackers@lists.postgresql.org>
Subject: Re: Have I found an interval arithmetic bug?
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>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Wed, 28 Jul 2021 12:32:03 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <593113.1627491944.1@sss.pgh.pa.us>
Date: Wed, 28 Jul 2021 13:05:44 -0400
Message-ID: <593114.1627491944@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/593114.1627491944%40sss.pgh.pa.us>
Precedence: bulk

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