Re: comment regarding double timestamps; and, infinite timestamps and NaN

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: comment regarding double timestamps; and, infinite timestamps and NaN
Date: 2019-12-30 14:05:24
Message-ID: 3233.1577714724@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Justin Pryzby <pryzby(at)telsasoft(dot)com> writes:
> selfuncs.c convert_to_scalar() says:
> |* The several datatypes representing absolute times are all converted
> |* to Timestamp, which is actually a double, and then we just use that
> |* double value.

> So I propose it should say something like:

> |* The several datatypes representing absolute times are all converted
> |* to Timestamp, which is actually an int64, and then we just promote that
> |* to double.

Check, obviously this comment never got updated.

> That seems to be only used for ineq_histogram_selectivity() interpolation of
> histogram bins. It looks to me that at least isn't working for "special
> values", and needs to use something other than isnan().

Uh, what? This seems completely wrong to me. We could possibly
promote DT_NOBEGIN and DT_NOEND to +/- infinity (not NaN), but
I don't really see the point. They'll compare to other timestamp
values correctly without that, cf timestamp_cmp_internal().
The example you give seems to me to be working sanely, or at least
as sanely as it can given the number of histogram points available,
with the existing code. In any case, shoving NaNs into the
computation is not going to make anything better.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-12-30 14:10:40 Re: TAP testing for psql's tab completion code
Previous Message Tom Lane 2019-12-30 13:28:09 Re: Windows v readline