Re: Infinite Interval
Joseph Koshakow <koshy44@gmail.com>
From: Joseph Koshakow <koshy44@gmail.com>
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
"Gregory Stark (as CFM)" <stark.cfm@gmail.com>, jian he <jian.universality@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-04-02T21:25:50Z
Lists: pgsql-hackers
Attachments
- 0004-Clean-up-infinity-arithmetic.patch (text/x-patch) patch 0004
> > This code is duplicated in timestamp_pl_interval(). We could create a function > > to encode the infinity handling rules and then call it in these two places. The > > argument types are different, Timestamp and TimestampTz viz. which map to in64, > > so shouldn't be a problem. But it will be slightly unreadable. Or use macros > > but then it will be difficult to debug. > > > > What do you think? > > I was hoping that I could come up with a macro that we could re-use for > all the similar logic. If that doesn't work then I'll try the helper > functions. I'll update the patch in a follow-up email to give myself some > time to think about this. So I checked where are all the places that we do arithmetic between two potentially infinite values, and it's at the top of the following functions: - timestamp_mi() - timestamp_pl_interval() - timestamptz_pl_interval_internal() - interval_pl() - interval_mi() - timestamp_age() - timestamptz_age() I was able to get an extremely generic macro to work, but it was very ugly and unmaintainable in my view. Instead I took the following steps to clean this up: - I rewrote interval_mi() to be implemented in terms of interval_um() and interval_pl(). - I abstracted the infinite arithmetic from timestamp_mi(), timestamp_age(), and timestamptz_age() into a helper function called infinite_timestamp_mi_internal() - I abstracted the infinite arithmetic from timestamp_pl_interval() and timestamptz_pl_interval_internal() into a helper function called infinite_timestamp_pl_interval_internal() The helper functions return a bool to indicate if they set the result. An alternative approach would be to check for finiteness in either of the inputs, then call the helper function which would have a void return type. I think this alternative approach would be slightly more readable, but involve duplicate finiteness checks before and during the helper function. I've attached a patch with these changes that is meant to be applied over the previous three patches. Let me know what you think. With this patch I believe that I've addressed all open comments except for the discussion around whether we should check just the months field or all three fields for finiteness. Please let me know if I've missed something. Thanks, 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