Re: @ versus ~, redux

Andrew Dunstan <andrew(at)dunslane(dot)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