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.
