>> In create_opclass.sgml, not only do we have the list of AMs supporting >> STORAGE, but there is also a paragraph describing which AMs do what >> for input datatypes of FUNCTION members (around line 175). > > I placed BRIN together with gist/gin/spgist here, namely that the optype > defaults to the opclass' datatype.
Requiring STORAGE type for BRIN opclasses is more of a bug than a feature. None of the operator classes actually support storing values with different type. We had intended to support it for inclusion opclass to index points by casting them to box, but then ripped it out because of inconsistencies on the operators caused by floating point arithmetics. The problem is that the operator classes try to query the strategies using the datatype they got from TupleDesc structure. It fails at least for cidr, because it is casted implicitly and indexed as inet. All of the BRIN operator classes can fail the same way for user defined types. Adding STORAGE to all operator classes have seemed to me like an easy fix at the time I noticed this problem, but what we really need to do is to fix this than document. We should to make BRIN use the datatype of the operator class as btree does. > + of each operator class interpret the strategy nnumbers according to the Typo: nnumbers. > + Operator classes based on the <literal>Inclusion</> framework can > + theoretically support cross-data-type operations, but there's no > + demonstrating implementation yet. This part of the inclusion class is not committed, so this paragraph shouldn't be there. Other than those, the changes look good to me. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
