Re: Behavior of equality_oper and ordering_oper

Sounds good to me too.

---------------------------------------------------------------------------

Joe Conway wrote:
> 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
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073