Re: Behavior of equality_oper and ordering_oper

Поиск
Список
Период
Сортировка
От Joe Conway
Тема Re: Behavior of equality_oper and ordering_oper
Дата
Msg-id 3F3D1F1C.6070203@joeconway.com
обсуждение исходный текст
Ответ на Behavior of equality_oper and ordering_oper  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Behavior of equality_oper and ordering_oper  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
Tom Lane wrote:
> Today it occurred to me that we could look in pg_opclass for a default
> btree opclass for the datatype.  If we find one, then the Equal and Less
> members of the opclass are the operators we want.  (If we don't find
> one, we could try for a default hash opclass, which would give us Equal,
> but not Less, for a few additional datatypes.)  This seems like a much
> cleaner approach for two reasons: the opclass structure declares
> directly that the operators have the semantics we are looking for,
> and the search is not dependent on schema visibility.  (We only allow
> one default opclass per datatype/AM, so the result would be unique.)

This sounds like a big improvement.

> In several of these cases, equality_oper is actually wrong --- box_eq
> for example compares areas, which is not what one would consider the
> normal equality behavior for boxes.  The only ones that really ought
> to be found are the ones for TID, MONEY, and ACLITEM.  I'm not
> particularly concerned about losing the ability to group by any of those
> datatypes, but if anyone is, we could talk about forcing an initdb to
> add the necessary comparison operators.

I'd go for the initdb.

Joe



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

Предыдущее
От: Andreas Pflug
Дата:
Сообщение: Re: [GENERAL] 7.4Beta
Следующее
От: "Dann Corbit"
Дата:
Сообщение: Re: [GENERAL] 7.4Beta