Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Jul 6, 2020 at 12:10 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> We did indeed solve this in connection with window functions, cf
>> 0a459cec9. I may be misunderstanding what the problem is here,
>> but I think trying to reuse that infrastructure might help.
> Ah, nice. I didn't realize that we'd added that. But I'm not sure that
> it helps here, because I think we need to compute the end of the
> range, not just test whether something is in a range.
Yeah, I was thinking about that later, and I agree that the in_range
support function doesn't quite do the job. But we could expand on the
principle, and register addition (and subtraction?) functions as btree
support functions under the same rules as for in_range functions.
The reason in_range isn't just addition is that we wanted it to be able
to give correct answers even in cases where addition would overflow.
That's still valid for that use-case, but it doesn't apply here.
So it'd be something like "btree support function 4, registered under
amproclefttype x and amprocrighttype y, must have the signature
plus(x, y) returns x
and it gives results compatible with the opfamily's ordering of type x".
Similarly for subtraction if we think we need that.
I'm not sure if we need a formal notion of what "compatible results"
means, but it probably would be something like "if x < z according to the
opfamily sort ordering, then plus(x, y) < plus(z, y) for any given y".
Now this falls to the ground when y is a weird value like Inf or NaN,
but we'd want to exclude those as partitioning values anyway. Do we
also need some datatype-independent way of identifying such "weird
values"?
regards, tom lane