Re: ExecBuildGroupingEqual versus collations

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)

postgres=>

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

To me, this suggests that we have already made this decision. Any type that
needs an "almost but not quite equality" concept needs to define a custom
operator or function. I think this is a reasonable approach to take for
collation-related issues.

Interesting relevant Python observation:

>>> a = float ('NaN')
>>> a is a
True
>>> a == a
False
>>>

So Python works quite differently from Postgres in this respect (and many
others).