On 02.12.23 19:41, Paul Jungwirth wrote:
> So what do you think of this idea instead?:
>
> We could add a new (optional) support function to GiST that translates
> "well-known" strategy numbers into the opclass's own strategy numbers.
> This would be support function 12. Then we can say
> translateStrategyNumber(RTEqualStrategyNumber) and look up the operator
> with the result.
>
> There is not a performance hit, because we do this for the DDL command
> (create pk/uq/fk), then store the operator in the index/constraint.
>
> If you don't provide this new support function, then creating the
> pk/uq/fk fails with a hint about what you can do to make it work.
>
> This approach means we don't change the rules about GiST opclasses: you
> can still use the stranums how you like.
>
> This function would also let me support non-range "temporal" foreign
> keys, where I'll need to build queries with && and maybe other operators.
I had some conversations about this behind the scenes. I think this
idea makes sense.
The other idea was that we create new strategy numbers, like
TemporalEqualsStrategy / TemporalOverlapsStrategy. But then you'd have
the situation where some strategy numbers are reserved and others are
not, so perhaps that is not so clean. I think your idea is good.