Le comportement du bit PostgreSQL et bit varying types est extrêmement inutile, avec la façon dont il refuse d'étendre les champs de bits pour les opérations, et il les étend à droite pour les conversions au lieu de les étendre à gauche.
Il serait logique que Pg étende à gauche le plus petit opérande avec des zéros avant une opération AND ou OR, plutôt que d'échouer.
Vous ne pouvez pas utiliser un cast pour bit(n) pour obtenir les mêmes longueurs, car pour une raison insensée, un cast en bit(n) coussinets droits l'argument, le rendant inutile dans presque toutes les situations.
Vous pouvez utiliser quelque chose comme lpad($1::text, greatest(length($1), length($2)),'0')::bit varying pour étendre à gauche un champ de bits avec des zéros à la plus grande de deux longueurs. C'est encombrant, mais ça ira. Je recommanderais d'écrire des fonctions wrapper pour contenir le désordre.
Vous pouvez également envisager de modifier le bit prendre en charge le code dans src/backend/utils/adt/varbit.c pour ajouter des fonctions aux champs de bits étendus à gauche et tronqués à gauche, et des fonctions pour effectuer des comparaisons d'extension à gauche. Cela devrait être assez facile sur la base du code existant.
