Time series point type/interface

[davidkohn88]

In multiple cases we need to pass in a time and a value as a single object to various functions (in subqueries etc) having a type that is made for this would be useful.

One case is in our discussion of time_weighted_average (#52) - here we have an example of a prev clause where as originally written, I don't think it'll work:

WITH t as (SELECT time_bucket('5 min', ts) as bucket, tw_agg(ts, value, method=>'locf')
    FROM foo
    WHERE ts > '2020-10-01' and ts <= '2020-10-02'
    GROUP BY 1 )
SELECT bucket, time_weighted_average(tw_agg, prev=>(SELECT ts, value FROM foo WHERE ts < '2020-10-01' ORDER BY ts DESC LIMIT 1)) OVER (ORDER BY bucket ASC )
FROM t;

the prev subselect returns two values, which, given that it's one input seems like it would actually be a syntax error.

So here I'd propose we make a ts_point type/interface that combined them into single type.

This avoids the need to split this intoprev_time & prev_value subselects/parameters and is a useful interface.

There's a question of how this type would be implemented, would there be multiple different types varying based on the types of the timestamp and the value (ie ts_point_timestamptz_double, ts_point_bigint_double, ts_point_timestamptz_numeric etc. ) or would we have one type that somehow kept that information internally. How will this play with Rust generics in either case? (this same problem sort of exists for any of the aggregate types as well)

I think that most of this could be hidden for the user behind a simple function interface, the prev subselect should simply become:

 prev=>(SELECT ts_point(ts, value) FROM foo WHERE ts < '2020-10-01' ORDER BY ts DESC LIMIT 1)) OVER (ORDER BY bucket ASC )

And that function would be overloaded, returning different types based on the input types and then the window function would simply have to be defined on all the different possible ts_points etc. which uses the overloading system reasonably nicely. I think we'd have to see how much administrative burden there is to generating all those function signatures and running tests over all of them, but we're going to need to support it somehow...