Tom Lane writes:
> Actually the other way around. An opclass is the subset of an opfamily
> that is tightly bound to an index. The "build" methods have to be
> associatable with an index, so they're part of the index's opclass.
> The "query" methods could be loose in the opfamily.
I had underst
Dimitri Fontaine writes:
> For the GIN indexes, we have 2 methods for building the index and 3
> others to search it to solve the query. You're proposing that the 2
> former methods would be in the opfamily and the 3 later in the opclass.
Actually the other way around. An opclass is the subset
Tom Lane writes:
> 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
Robert Haas writes:
> On Wed, Jan 19, 2011 at 1:33 PM, Tom Lane wrote:
>> AFAICS that means integrating contrib/intarray into core. Independently
>> of whether that's a good idea or not, PG is supposed to be an extensible
>> system, so it would be nice to have a solution that supported add-on
>>
On Wed, Jan 19, 2011 at 1:33 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jan 19, 2011 at 12:29 PM, Tom Lane wrote:
>>> 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 ha
Robert Haas writes:
> On Wed, Jan 19, 2011 at 12:29 PM, Tom Lane wrote:
>> 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
On Wed, Jan 19, 2011 at 12:29 PM, Tom Lane wrote:
> Dimitri Fontaine writes:
>> Tom Lane 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 o
Dimitri Fontaine writes:
> Tom Lane 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 th
Tom Lane 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 i
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
10 matches
Mail list logo
