Re: ExecBuildGroupingEqual versus collations
| От | Isaac Morland |
|---|---|
| Тема | Re: ExecBuildGroupingEqual versus collations |
| Дата | |
| Msg-id | CAMsGm5f6EF9+Ks=CKn1g70UQ2hKKW4EbrkZpjRmjKS1FcS6Wog@mail.gmail.com обсуждение исходный текст |
| Ответ на | ExecBuildGroupingEqual versus collations (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: ExecBuildGroupingEqual versus collations
|
| Список | pgsql-hackers |
On Fri, 14 Dec 2018 at 14:25, Tom Lane <tgl@sss.pgh.pa.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).
В списке pgsql-hackers по дате отправления: