On Sat, Dec 15, 2018 at 3:02 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2018-12-15 14:43:49 -0500, Tom Lane wrote:
> >> Note that timestamp_lt etc don't actually need any special case for
> >> infinity, and we could hope that the infinity representation for interval
> >> makes it possible to likewise not special-case it in interval comparisons.
> >> But I think it's silly to argue that infinity handling is a significant
> >> fraction of something like timestamp_pl_interval or timestamp_part.
>
> > I'm inclined to agree that if done carefully the overhead here is
> > probably acceptable.
>
> Backing up to look at the actual code ... if the infinity representation
> is the max or min value in each of the three fields, then the conversion
> done by interval_cmp_value would yield an int128 value that's certainly
> greater than or less than any other interval value, and I don't think it
> can overflow, so there's no need to add any code to the comparison cases.
OK, well, I stand corrected. Not sure that answers the question of
whether we want this, but it's nice to know that if we do, it can be
done without causing too much slowdown.
Simon's argument for adding this is that we support 'infinity' for
timestamp, but is that a good argument for making 'interval' do it,
given that there are many other types like date for which we don't
support it?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company