Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Jul 23, 2021 at 5:47 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Hmm. Note that what this is checking for is same operator *class* not
>> same operator family (if it were doing the latter, Peter's case would
>> already work). I think it has to do that. Extending my previous
>> thought experiment about an unsigned integer type, if someone were to
>> invent one, it would make a lot of sense to include it in integer_ops,
>> and then the logic you suggest is toast.
> Mumble. I hadn't considered that sort of thing. I assumed that when
> the documentation and/or code comments talked about a compatible
> notion of equality, it was a strong enough notion of "compatible" to
> preclude this sort of case.
For btree indexes, you need a compatible notion of ordering, not only
equality. That's really what's breaking my hypothetical case of a uint
type. But as long as you implement operators that behave in a consistent
fashion, whether they interpret the same heap bitpattern the same is not
something that matters for constructing a consistent operator family.
datetime_ops (which includes timestamp and timestamptz) is already a
counterexample, since unless the timezone is UTC, its operators *don't*
all agree on what a particular bitpattern means.
>> ... I'm also a bit confused about how it ever succeeds at all.
> Well, you can change just the typemod, for example, which was a case
> that motivated this work originally.
Ah, right. I guess binary-compatible cases such as text and varchar
would also fit into that.
regards, tom lane