Re: Implied Functional Index use

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Implied Functional Index use
Дата
Msg-id 6768.1152653464@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Implied Functional Index use  (Simon Riggs <simon@2ndquadrant.com>)
Ответы Re: Implied Functional Index use  (Peter Eisentraut <peter_e@gmx.net>)
Re: Implied Functional Index use  (Simon Riggs <simon@2ndquadrant.com>)
Список pgsql-hackers
Simon Riggs <simon@2ndquadrant.com> writes:
> ...
> - add a new boolean to pg_operator to allow us to define which operators
> offer true equality
> ...

This would be useful for other purposes too, as we keep coming up
against "what's the equality operator for this datatype" problems.
However, the restriction to "true" equality, such that we can assume
x = y implies f(x) = f(y) for every immutable function f on the datatype
(note this need not necessarily mean bitwise equality --- it depends on
what operations the datatype provides), seems like a problem.  For
instance, the ordinary = operators on float and numeric are NOT true
equality, nor do we provide any true equality in this sense for these
common datatypes.  We could hardly get away with using this concept
to drive foreign-key comparisons, if it doesn't work for float or
numeric.

We could invent some more-complex concept involving "well, this is
equality, but there are some functions for which f(x) might differ
from f(y) anyway" and then mark the presumably-few functions that
could produce divergent results --- examples are sgn() for float8
and anything dependent on dscale for numeric.  This seems ugly and
error prone however.

Anyone have a better idea?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Marc G. Fournier"
Дата:
Сообщение: Re: Three weeks left until feature freeze
Следующее
От: Robert Treat
Дата:
Сообщение: Re: More nuclear options