Re: ExecBuildGroupingEqual versus collations

Isaac Morland <isaac(dot)morland(at)gmail(dot)com> writes:
> On Fri, 14 Dec 2018 at 14:25, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Now, it's certainly true that nameeq() doesn't need a collation spec
>> today, any more than texteq() does, because both types legislate that
>> equality is bitwise. But if we leave ExecBuildGroupingEqual like this,
>> we're mandating that no type anywhere, ever, can have a
>> collation-dependent notion of equality. Is that really a restriction
>> we're comfortable with? citext is sort of the poster child here,
>> because it already wishes it could have collation-dependent equality.

> There already seems to be a policy that individual types are not allowed to
> have their own concepts of equality:
> postgres=> select 'NaN'::float = 'NaN'::float;
> ?column?
> ----------
> t
> (1 row)

> According to the IEEE floating point specification, this should be f not t.

I don't think that's a particularly relevant counter-example. The problem
with following the IEEE spec for that is that it breaks pretty much
everybody's notion of equality, in particular the reflexive axiom (A=A for
any A), which is one of the axioms needed for btrees to work. That does
*not* preclude allowing non-bitwise-equal values to be considered equal,
which is the case that citext would like --- and, indeed, a case that IEEE
math also requires (0 = -0), and which we do support for floats.

regards, tom lane