Robert Haas <robertmh...@gmail.com> writes: > On Mon, Jul 6, 2020 at 12:10 PM Tom Lane <t...@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