On Fri, 14 Dec 2018 at 14:25, Tom Lane <[email protected]> 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).
