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
|
Список | 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 по дате отправления: