api: specify inclusive min/max filters

[pro-wh]

we had a lot of these min/max filters. the queries use >= <=, so I'm entering these as inclusive

actually the time ones are kinda not right to be called simply "inclusive." if I say the max time is 2022 oct 20, that doesn't mean a block etc from 2022 oct 20 at 9 PM is "included," right? it's only if the timestamp is exactly 2022 oct 20 00:00:00 and zero microseconds, then that's equal to the provided max time and that's included. but up to 999 nanoseconds is fine because that'll be lost when it gets converted from Go to postgresql. hm.

or am I wrong about the above?

[mitjat]

That's my understanding of how times work too, yes. Tricky to describe the behavior correctly and succinctly ...

WDYT about changing the queries to be inclusive on the lower limit and exclusive on the upper? (i.e. >= and <)
That would make times behave naturally. And it would give us an API that is (in my experience) in line with most other range-related APIs (e.g. python slices). It also would make it easier to "scan" a range with multiple queries (e.g. fetching tx with fees from the interval [A,B), then from [B,C), etc; not that I have a great use case for that :).

[aefhm]

I like the scanning idea.

actually the time ones are kinda not right to be called simply "inclusive." if I say the max time is 2022 oct 20, that doesn't mean a block etc from 2022 oct 20 at 9 PM is "included," right?

I think the inclusive search is more "expected?" People normally think of it as an UTC timestamp comparison?

[aefhm]

I'm cool with the description change.

[pro-wh]

interesting, I think the pagination idea from earlier wanted that too. although it would go backwards: [-inf, inf) limit 20, then you look at the earliest one B and request [-inf, B) limit 20, etc.

[pro-wh]

filed 203. let's merge this