Création implicite de familles d'opérateurs

[alhyss]

La v1.4.0 prendra en charge les classes et familles d'opérateurs (déjà implémenté).

Je suis tombée sur un bug de PostgreSQL en testant la mise en conformité des propriétaires. Lorsqu'on lance une commande CREATE OPERATOR CLASS sans spécifier le paramètre FAMILY, une famille d'opérateurs de même nom que la classe d'opérateurs est automatiquement créée si elle n'existait pas déjà (cf. doc). Mais pg_event_trigger_ddl_commands() ne renvoie que la création de la classe.

J'ai signalé le problème et il devrait être corrigé dans les versions mineures qui sortiront en août 2022.

Pour l'heure, la fonction z_asgard_admin.asgard_on_create_objet() de la v1.4.0 d'Asgard en cours de développement intègre un palliatif. Si pg_event_trigger_ddl_commands() renvoie une classe d'opérateurs, elle examine sa famille d'opérateurs. Si celle-ci porte le même nom que la classe et se trouve dans le même schéma, elle corrige si besoin son propriétaire.

                    IF obj.object_type = 'operator class' AND EXISTS (
                        SELECT * FROM pg_catalog.pg_opclass
                            LEFT JOIN pg_catalog.pg_opfamily
                                ON pg_opfamily.oid = opcfamily
                            WHERE obj.objid = pg_opclass.oid
                                AND opfname = opcname
                                AND opfmethod = opcmethod
                                AND opfnamespace = opcnamespace
                                AND NOT opfowner = quote_ident(roles.producteur)::regrole
                        )
                    THEN
                        l := format('ALTER operator family %s OWNER TO %I',
                            obj.object_identity, roles.producteur) ;
                        EXECUTE l ;
                        RAISE NOTICE '> %', l ;
                    END IF ;

Ces commandes n'auront plus lieu d'être après l'application du correctif, puisque la nouvelle famille d'opérateurs sortira aussi dans la boucle sur le résultat de pg_event_trigger_ddl_commands(). La redondance ne créera pas d'anomalie, elle complexifiera juste le code pour rien.

La question est de savoir si la v1.4.0 doit être diffusée avec ou sans ce bricolage.

À noter aussi que le correctif ne sera pas porté sur PostgreSQL 9.5, qui reste officiellement pris en charge pour Asgard.

Pour mémoire, c'est l'assertion 8 du test z_asgard_recette.t056() qui échoue actuellement sans le palliatif.

[alhyss]

Correction effective dans la version 14.4 de PostgreSQL diffusée le 16 juin 2022 : "Report implicitly-created operator families (generated by CREATE OPERATOR CLASS) to event triggers". Cf. annonce de publication et note de version.

Non rétro-porté dans les versions antérieures à ce stade, mais probablement juste parce que seule la v14 a été mise à jour en juin, hors calendrier normal (prochaines versions mineures prévues pour le 11 août 2022).

[alhyss]

Le correctif a été rétro-porté dans les versions 13.8, 12.12, 11.17 et 10.22 publiées le 11 août 2022.

Report implicitly-created operator families to event triggers (Masahiko Sawada)

If CREATE OPERATOR CLASS results in the implicit creation of an operator family, that object was not reported to event triggers that should capture such events.

La version 1.4.0 est publiée avec le palliatif mentionné ci-avant, qui doublonne donc le véritable correctif intégré aux dernières versions mais assure la compatibilité avec la version 9.5. Ces commandes seront à supprimer dans la première version d'AsgardPostgreSQL qui ne prendra officiellement plus en charge PostgreSQL 9.5.