Operator families vs. casts

PostgreSQL 9.1 will implement ALTER TABLE ALTER TYPE operations that use a
binary coercion cast without rewriting the table or unrelated indexes. It
will always rewrite any indexes and recheck any foreign key constraints that
depend on a changing column. This is unnecessary for 100% of core binary
coercion casts. In my original design[1], I planned to detect this by
comparing the operator families of the old and would-be-new indexes. (This
still yields some unnecessary rewrites; oid_ops and int4_ops are actually
compatible, for example.) When I implemented[2] it, I found that the
contracts[3] for operator families are not strong enough to prove that the
existing indexes and constraints remain valid. Specifically, I wished assume
val0 = val1 iff val0::a = val1::b for any val0, val1, a, b such that we
resolve both equality operators in the same operator family. The operator
family contracts say nothing about consistency with casts. Is there a
credible use case for violating that assumption? If not, I'd like to document
it as a requirement for operator family implementors.

The above covers B-tree and hash operator families. GIN and GiST have no
operator family contracts. Here was the comment in my first patch intended to
sweep that under the table:

! * We do not document a contract for GIN or GiST operator families. Only the
! * GIN operator family "array_ops" has more than one constituent operator class,
! * and only typmod-only changes to arrays can avoid a rewrite. Preserving a GIN
! * index across such a change is safe. We therefore support GiST and GIN here
! * using the same rules as for B-tree and hash indexes, but that is mostly
! * academic. Any forthcoming contract for GiST or GIN operator families should,
! * all other things being equal, bolster the validity of this assumption.
! *
! * Exclusion constraints raise the question: can we trust that the operator has
! * the same semantics with the new type? The operator will fall in the index's
! * operator family. For B-tree or hash, the operator will be "=" or "<>",
! * yielding an affirmative answer from contractual requirements. For GiST and
! * GIN, we assume that a similar requirement would fall out of any contract for
! * their operator families, should one arise. We therefore support exclusion
! * constraints without any special treatment, but this is again mostly academic.

Any thoughts on what to do here? We could just add basic operator family
contracts requiring what we need. Perhaps, instead, the ALTER TABLE code
should require an operator family match for B-tree and hash but an operator
class match for other access methods.

For now, I plan to always rewrite indexes on expressions or having predicates.
With effort, we could detect compatible changes there, too.

I also had a more mundane design question in the second paragraph of [2]. It
can probably wait for the review of the next version of the patch. However,
given that it affects a large percentage of the patch, I'd appreciate any
early feedback on it.

Thanks,
nm

[1] http://archives.postgresql.org/message-id/20101229125625.GA27643@tornado.gateway.2wire.net
[2] http://archives.postgresql.org/message-id/20110113230124.GA18733@tornado.gateway.2wire.net
[3] http://www.postgresql.org/docs/9.0/interactive/xindex.html#XINDEX-OPFAMILY