> Once again, many thanks for the review. Here's a new version. I have
> added operator classes for int8, text, and actually everything that btree
> supports except:
> bool
> record
> oidvector
> anyarray
> tsvector
> tsquery
> jsonb
> range
>
> since I'm not sure that it makes sense to have opclasses for any of
> these -- at least not regular minmax opclasses. There are some
> interesting possibilities, for example for range types, whereby we store
> in the index tuple the union of all the range in the block range.
I thought we can do better than minmax for the inet data type,
and ended up with a generalized opclass supporting both inet and range
types. Patch based on minmax-v20 attached. It works well except
a few small problems. I will improve the patch and add into
a commitfest after BRIN framework is committed.
To support more operators I needed to change amstrategies and
amsupport on the catalog. It would be nice if amsupport can be set
to 0 like amstrategies.
Inet data types accept IP version 4 and version 6. It is not possible
to represent union of addresses from different versions with a valid
inet type. So, I made the union function return NULL in this case.
Then, I tried to store if returned value is NULL or not, in
column->values[] as boolean, but it failed on the pfree() inside
brin_dtuple_initilize(). It doesn't seem right to free the values
based on attr->attbyval.
I think the same opclass can be used for geometric types. I can
rename it to inclusion_ops instead of range_ops. The GiST opclasses
for the geometric types use bounding boxes. It wouldn't be possible
to use a different data type in a generic oplass. Maybe STORAGE
parameter can be used for that purpose.
> (I had an opclass for anyenum too, but on further thought I removed it
> because it is going to be pointless in nearly all cases.)
It can be useful in some circumstances. We wouldn't lose anything
by supporting more types. I think we should even add an operator
class for boolean.
