> Judging from a quick look, I think patches 1 and 5 can be committed > quickly; they imply no changes to other parts of BRIN. (Not sure why 1 > and 5 are separate. Any reason for this?) Also patch 2.
Not much reason except that 1 includes only functions, but 5 includes operators. > Patch 4 looks like a simple bugfix (or maybe a generalization) of BRIN > framework code; should also be committable right away. Needs a closer > look of course. > > Patch 3 is a problem. That code is there because the union proc is only > used in a corner case in Minmax, so if we remove it, user-written Union > procs are very likely to remain buggy for long. If you have a better > idea to test Union in Minmax, or some other way to turn that stuff off > for the range stuff, I'm all ears. Just lets make sure the support > procs are tested to avoid stupid bugs. Before I introduced that, my > Minmax Union proc was all wrong. I removed this test because I don't see a way to support it. I believe any other implementation that is more complicated than minmax will fail in there. It is better to cache them with the regression tests, so I tried to improve them. GiST, SP-GiST and GIN don't have similar checks, but they have more complicated user defined functions. > Patch 7 I don't understand. Will have to look closer. Are you saying > Minmax will depend on Btree opclasses? I remember thinking in doing it > that way at some point, but wasn't convinced for some reason. No, there isn't any additional dependency. It makes minmax operator classes use the procedures from the pg_amop instead of adding them to pg_amproc. It also makes the operator class safer for cross data type usage. Actually, I just checked and find out that we got wrong answers from index on the current master 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; inclusion-opclasses patch make it possible to add cross type brin regression tests. I will add more of them on the next version. > Patch 6 seems the real meat of your own stuff. I think there should be > a patch 8 also but it's not attached ... ?? I had another commit not to intended to be sent. Sorry about that. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers