Re: Implied Functional Index use

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Implied Functional Index use
Дата
Msg-id 1152742281.2654.74.camel@localhost.localdomain
обсуждение исходный текст
Ответ на Re: Implied Functional Index use  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Implied Functional Index use  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Implied Functional Index use  ("Zeugswetter Andreas DCP SD" <ZeugswetterA@spardat.at>)
Список pgsql-hackers
On Tue, 2006-07-11 at 17:31 -0400, Tom Lane wrote:
> 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.

Normally, I would not suggest that we do things only for certain data
types only. In this case however, it seems that the reason it would work
only for INTEGER and TEXT data types is that they are simple atomic
datatypes that have the required properties. So doing this for those
datatypes only seems permissable on a theoretical basis, rather than
just because we can't be bothered to do it for more complex types.

--  Simon Riggs EnterpriseDB          http://www.enterprisedb.com



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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Online index builds
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: lastval exposes information that currval does not