>> 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.