Re: Infinite Interval - Mailing list pgsql-hackers

From Joseph Koshakow
Subject Re: Infinite Interval
Date
Msg-id CAAvxfHds_e5ZUfd7trTD8T03=rLrrjK+yXWEG-k66GnsgKh_pA@mail.gmail.com
Whole thread Raw
In response to Re: Infinite Interval  (Joseph Koshakow <koshy44@gmail.com>)
Responses Re: Infinite Interval
List pgsql-hackers
> > 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
Attachment

pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Minimal logical decoding on standbys
Next
From: Nathan Bossart
Date:
Subject: Re: O(n) tasks cause lengthy startups and checkpoints