Anastasia Lubennikova <a.lubennik...@postgrespro.ru> wrote: > I attached new version with pg_opclass documentation update. > > One more thing I am uncertain about is array_ops. Arrays may contain bitwise > and not bitwise element types. > What is the correct value of opcisbitwise the array_ops itself?
How about setting opcisbitwise to false for the array_ops opclass and checking opcisbitwise of the element type whenever we need to know whether the array is "bitwise equal"? When checking array_eq(), I thought whether the existence of "expanded array" format is a problem but it does not seem to be: the conversion of "expanded" value to "flat" value and then back to the "expanded" should not change the array contents. Anyway, in the current version of the patch I see that array_ops opclasses have opcisbitwise=true. It should be false even if you don't use the approach of checking the element type. Besides that, I think that record_ops is similar to array_ops and therefore it should not set opcisbitwise to true. I also remember that, when thinking about the problem in the context of the aggregate push down patch, I considered some of the geometric types problematic. For example, box_eq() uses this expression #define FPeq(A,B) (fabs((A) - (B)) <= EPSILON) so equality does not imply bitwise equality here. Maybe you should only set the flag for btree opclasses for now. -- Antonin Houska Web: https://www.cybertec-postgresql.com
