Re: Expand applicability of aggregate's sortop optimization

On 18/7/2024 14:49, Matthias van de Meent wrote:
> Aside: Arguably, checking for commutator operators would not be
> incorrect when looking at it from "applied operators" point of view,
> but if that commutative operator isn't registered as opposite ordering
> of the same btree opclass, then we'd probably break some assumptions
> of some aggregate's sortop - it could be registered with another
> opclass, and that could cause us to select a different btree opclass
> (thus: ordering) than is indicated to be required by the aggregate;
> the thing we're trying to protect against here.
Hi,
This thread stands idle. At the same time, the general idea of this 
patch and the idea of utilising prosupport functions look promising. Are 
you going to develop this feature further?

-- 
regards, Andrei Lepikhov