Re: @ versus ~, redux

Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>>> 3. Leave the existing op names as-is in core and contrib, but consider
>>>    them deprecated and add new ops with consistently-chosen names.
>>>    (The new ops introduced by GIN should only exist with the new names.)

> You're right. I misread your original proposal.  I vote for #3.

OK, so if everyone is leaning to #3, the name game remains to be played.
Do we all agree on this:
"x @> y" means "x contains y""x @< y" means "x is contained in y"

Are we all prepared to sign a solemn oath to commit hara-kiri if we
invent a new datatype that gets this wrong?  No?  Maybe these still
aren't obvious enough.

BTW, even with the gist_consistent hack there's still a bit of a
technical problem: pg_operator can represent the knowledge that @> and
@< are commutators, and that @ and ~ are commutators, but not (at the
same time) that @> and @ are commutators.  This is not a fatal objection
but it's a tad annoying --- I think there are cases where the planner
would miss possible optimizations if it can't see this.  Anybody see a
suitably low-cost fix?  Does it not matter if every GIST opclass has
mappings for both operator pairs?
        regards, tom lane