Re: BRIN range operator class

> Can you please explain what is the purpose of patch 07? I'm not sure I
> understand; are we trying to avoid having to add pg_amproc entries for
> these operators and instead piggy-back on btree opclass definitions?
> Not too much in love with that idea; I see that there is less tedium in
> that the brin opclass definition is simpler. One disadvantage is a 3x
> increase in the number of syscache lookups to get the function you need,
> unless I'm reading things wrong. Maybe this is not performance critical.

It doesn't use btree opclass definitions. It uses brin opclass
pg_amop entries instead of duplicating them in pg_amproc.
The pg_amproc.h header says:

> * The amproc table identifies support procedures associated with index
> * operator families and classes. These procedures can't be listed in pg_amop
> * since they are not the implementation of any indexable operator.

In our case, these procedures can be listed in pg_amop as they
are implementations of indexable operators.

The more important change on this patch is to request procedures for
the right data types. Minmax opclasses return wrong results without
this patch. You can reproduce it with this query on
the regression database:

select * from brintest where timestampcol = '1979-01-29 11:05:09'::timestamptz;

> Anyway I tried applying it on isolation, and found that it fails the
> assertion that tests the "union" support proc in brininsert. That
> doesn't seem okay. I mean, it's okay not to run the test for the
> inclusion opclasses, but why does it now fail in minmax which was
> previously passing? Couldn't figure it out.

The regression tests passed when I tried it on the current master.