recall.enable(): When copying existing data, the start times should probably be set to null (i.e. an open interval start) instead of now()

[mreithub]

Right now, recall.enable() copies existing data from the data to the log table using now() as start timestamp. This is kind of a relic from a time when I used two separate timestamp fields (_log_start TIMESTAMPTZ NOT NULL and _log_end TIMESTAMPTZ). Back then, _log_start was non-null, so it couldn't reflect undefined values (although, now that I'm thinking of having the start timestamp of the initial data undefined, a nullable field would've been the better choice even back then).

tstzrange allows us to have infinite intervals for these preexisting records.

Implications:

• querying for data that's older than when the logging was enabled, you'll get (some or all of - depending on whether some of them have fallen victims of cleanup() yet) the initial data instead of an empty result.
• Sorting changes: When sorting by LOWER(_log_time), all the initial values end up at the end, when simply sorting by _log_time, the sorting is relatively unaffected, but you can't sort by anything else without also sorting by UPPER(_log_time).
  To properly sort only by the start time (and any other column, but not the end time), you'd have to use something like this: order by coalesce(lower(_log_time), '-infinity') asc or this: order by tstzrange(lower(_log_time), null) asc
• it brings up the point whether or not it might make sense to have recall.at() filter by the log interval and the timestamp stored in recall._config (i.e. when using it outside of the time range in which it can give you precise data, it'd return an empty result/error instead). I'll create another issue for that though.