Re: Infinite Interval
Joseph Koshakow <koshy44@gmail.com>
From: Joseph Koshakow <koshy44@gmail.com>
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-12-17T23:32:24Z
Lists: pgsql-hackers
Attachments
- v3-0001-Support-infinite-interval.patch (text/x-patch) patch v3-0001
On Sat, Dec 17, 2022 at 2:34 PM Joseph Koshakow <koshy44@gmail.com> wrote: > > Hi Ashutosh, > > I've added tests for all the operators and functions involving > intervals and what I think the expected behaviors to be. The > formatting might be slightly off and I've left the contents of the > error messages as TODOs. Hopefully it's a good reference for the > implementation. > > > Adding infinite interval to an infinite timestamp with opposite > > direction is not going to yield 0 but some infinity. Since we are adding > > interval to the timestamp the resultant timestamp is an infinity > > preserving the direction. > > I think I disagree with this. Tom Lane in one of the previous threads > said: > > tl;dr: we should model it after the behavior of IEEE float infinities, > > except we'll want to throw errors where those produce NaNs. > and I agree with this opinion. I believe that means that adding an > infinite interval to an infinite timestamp with opposite directions > should yield an error instead of some infinity. Since with floats this > would yield a NaN. > > > Dividing infinite interval by finite number keeps it infinite. > > TODO: Do we change the sign of infinity if factor is negative? > Again if we model this after the IEEE float behavior, then the answer > is yes, we do change the sign of infinity. > > - Joe Koshakow I ended up doing some more work in the attached patch. Here are some updates: - I modified the arithmetic operators to more closely match IEEE floats. Error messages are still all TODO, and they may have the wrong error code. - I implemented some more operators and functions. - I moved the helper functions you created into macros in timestamp.h to more closely match the implementation of infinite timestamps and dates. Also so dates.c could access them. - There seems to be an existing overflow error with interval subtraction. Many of the arithmetic operators of the form `X - Interval` are converted to `X + (-Interval)`. This will overflow in the case that some interval field is INT32_MIN or INT64_MIN. Additionally, negating a positive infinity interval won't result in a negative infinity interval and vice versa. We'll have to come up with an efficient solution for this. - Joe Koshakow
Commits
-
Support +/- infinity in the interval data type.
- 519fc1bd9e9d 17.0 landed
-
Avoid integer overflow hazard in interval_time().
- 3850d4dec1d9 17.0 landed
-
Guard against overflow in make_interval().
- b2d55447a563 17.0 landed
-
Fix minmax-multi on infinite date/timestamp values
- 8da86d62a112 17.0 cited
-
Optimize various aggregate deserialization functions, take 2
- 0c882a298881 17.0 cited
-
Remove dead code in DecodeInterval()
- d6d1430f4043 17.0 cited
-
Accept "+infinity" in date and timestamp[tz] input.
- 2ceea5adb026 16.0 cited
-
Fix overflow hazards in interval input and output conversions.
- e39f99046710 15.0 cited