Tom Lane <tgl@sss.pgh.pa.us> writes:
> 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.
I would have though that such contrib would then need to offer their own
opfamily and opclasses, and users would have to use the specific opclass
manually like they do e.g. for text_pattern_ops. Can't it work that way?
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support