On Wed, Jan 19, 2011 at 12:29 PM, Tom Lane <[email protected]> wrote: > Dimitri Fontaine <[email protected]> writes: >> Tom Lane <[email protected]> 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. > >> 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? > > I think you missed the point: right now, to use both the core and > intarray operators on an integer[] column, you have to create *two* > GIN indexes, which will have exactly identical contents. I'm looking > for a way to let intarray extend the core opfamily definition so that > one index can serve.
Maybe this is a dumb question, but why not just put whatever stuff intarray[] adds directly into the core opfamily? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
