Andrew Dunstan <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
