Re: Behavior of equality_oper and ordering_oper - Mailing list pgsql-hackers

From Joe Conway
Subject Re: Behavior of equality_oper and ordering_oper
Date
Msg-id 3F3D1F1C.6070203@joeconway.com
Whole thread Raw
In response to Behavior of equality_oper and ordering_oper  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Behavior of equality_oper and ordering_oper
List 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 by date:

Previous
From: Andreas Pflug
Date:
Subject: Re: [GENERAL] 7.4Beta
Next
From: "Dann Corbit"
Date:
Subject: Re: [GENERAL] 7.4Beta