Anastasia Lubennikova <a.lubennikova@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
