I wrote:
> So here's what I'm thinking: we could redefine a GIN opclass, per se, as
> needing only compare() and extractValue() procs to be bound into it.
> The other three procs, as well as the query operators, could be "loose"
> in the containing opfamily. The index AM would choose which set of the
> other support procedures to use for a specific query by matching their
> amproclefttype/amprocrighttype to the declared input types of the query
> operator, much as btree does.
> Having done that, contrib/intarray could work by adding "loose"
> operators and support procs to the core opfamily for integer[].
Oh, wait a minute: there's a bad restriction there, namely that a
contrib module could only add "loose" operators that had different
declared input types from the ones known to the core opclass. Otherwise
there'd be a conflict with the contrib module and core needing to insert
similarly-keyed support functions. This would actually be enough for
contrib/intarray (because the core operator entries are for "anyarray"
not for "integer[]") but it is easy to foresee cases where that wouldn't
be good enough. Seems like we'd need an additional key column in
pg_amproc to really make this cover all cases.
regards, tom lane
