[Héritage] Bug à la suite d'un ALTER ?

Bonjour,

Je suis en Postgresql 8.3.3 sur Windows XP.
J'ai 2 schéma, avec dans le second une table héritée du premier schéma.
Voici les scripts de création :

Code:

---

1 2 3 4 5

create schema test1; create schema test2;   create table test1.point (code char(16), test1 char(2), test2 char(3)); create table test2.point (code2 char(16)) INHERITS (test1.point);

---

Je dois réaliser un script qui supprime la colonne test2.
Or, pour des raisons de maintenant, j'ai du faire "sauter" temporairement l'héritage de ma table point dans le schéma test2, comme ça :

Code:

---

1 2	alter table test2.point no inherit test1.point; alter table test2.point inherit test1.point;

---

Du coup, maintenant, alors que l'héritage a bien été rétabli, la suppression d'une colonne dans la table mère ne se propage plus dans la table fille :?.

Code:

---

alter table test1.point drop column test2 cascade;

---

La colonne test2 n'est plus dans test1.point, mais elle est toujours dans test2.point.
Pourtant, d'après la doc Postgresql, elle aurait aussi dû être supprimée... Et c'est bien ce qui se passe si je ne supprime pas temporairement l'héritage par la commande ALTER.

Est-ce que c'est un bug ?

ced

Bonjour
Du coup, maintenant, alors que l'héritage a bien été rétabli, la suppression d'une colonne dans la table mère ne se propage plus dans la table fille

Dans la documentation c'est très peu détaillé sur ce qui se passe réellement.
Je pense qu'il est interressant de décrire l'interaction sur un exemple pour
clarifier la chose avec ce sujet.
Exemple:
j'ai une table gr_ident qui comporte plusieurs milions d'enregistrements
Je crée un table fille inherit sub_gr_ident pour restreinde la charge.
La table fille sub_gr_ident reçoit 50 nouveaux enregistrements
La table mère gr_ident a donc maintenent également les 50 enregistrements
Je decide d'enlever la relation fille sub_gr_ident de la table gr_ident
alter table sub_gr_ident NO INHERIT gr_ident;
Là la table fille sub_gr_ident reste indentique les champs inherit deviennent
des champs a part entière.
La table gr_ident perd les 50 enregistrement saisies via son ex fille.
J'execute une rétro instruction pour voir ce qui se passe.
alter table sub_gr_ident INHERIT gr_ident;
et là je retrouve les 50 enregitrements de ma table fille sub_gr_ident dans ma table mère gr_ident.
Je nai pas testé votre manipe mais sauf erreur de ma part je pense qu' il faut supprimer le champs de la fille avant de reintergrer la mère ?? ce qui semble normal.
Cordialement

Merci pour ces propositions :) et pour l'intérêt que vous portez à mon problème.

Effectivement, j'ai oublié de préciser où se situaient les données.
Dans mon cas, les données sont au niveau de la table fille.
Toutefois, en exécutant le code que j'ai donné en exemple, sans mettre aucune donnée dans les tables, on reproduit le "bug". Ce n'est donc visiblement pas lié à la localisation des données :(.

Voilà ce que dit la documentation sur ce sujet :

Citation:

---

L'héritage de table est typiquement établi lors de la création de la table enfant en utilisant la clause INHERITS de l'instruction CREATE TABLE. Alternativement, il est possible d'ajouter à une table déjà définie de façon compatible une nouvelle relation de parenté à l'aide de la clause INHERIT de ALTER TABLE. Pour cela, la nouvelle table enfant doit déjà inclure des colonnes de mêmes nom et type que les colonnes de la table parent. Elle doit aussi contenir des contraintes de vérification de mêmes nom et expression que celles de la table parent.
De la même façon, un lien d'héritage peut être supprimé d'un enfant à l'aide de la variante NO INHERIT d'ALTER TABLE.

---

Ce qui est le cas dans mon exemple...
Et aussi, un peu plus loin :

Citation:

---

ALTER TABLE propage toute modification dans les définitions des colonnes et contraintes de vérification à travers la hiérarchie d'héritage.

---

J'ai essayé avec le mot-clef CASCADE, mais ça ne marche pas mieux... :bug:

ced

Un petit complément d'information : une fois l'héritage remis (après le second ALTER), je contrôle via le catalogue si les colonnes de la table fille sont bien marquées comme "héritées" (donnée attinhcount dans pg_attribute). Elles sont bien à 1, ce qui indique qu'il y a, théoriquement, héritage.

ced

ALTER TABLE propage toute modification dans les définitions des colonnes et contraintes de vérification à travers la hiérarchie d'héritage.
A mon avis ils ont oubliés d'ajouter(sur les champs similaires préxistants ou complementaires)(une action partielle et non globale).
Je vais faire des tests plus poussés pour mieux comprendre cette dynamique
Par exemple changer le type de champ de la fille en conservant le meme libellé commun aux deux table entre l'action et la rétro action.
Je pense que comme ça je vais réussir à le planter....
je vais moduler plusieurs INHERIT & NO INHERIT a partir de plusieurs mères pour voir si on peut envisager controler une table au contenu dynamique sur critère contextuel.
Cela semble trop simple pour être vraie ....
Cordialement

De 2 choses l'une : soit c'est un oubli de la documentation, soit c'est un bug de programmation... Non ?

ced

Je suis entièrement d'accord avec vous ,le nombre d'interactions possibles via cette
dynamique est énorme ,documenter globalement semble difficile, de même pour les developpeurs
qui n'anticipent pas toujours toutes les configurations possibles.
je vais vais mettre ulterieurement le résultat de mes tests sur cette échange
dans l'espoir d'apporter un peu plus de precisions.
Cordialement

J'ai fait remonter un bug aux équipes de Postgres sur ce sujet.
En réponse, on m'a dit que ce n'était pas vraiment un bug, que ça risquait de compliquer les mécanismes de l'héritage, mais que la documentation serait revue pour préciser les choses.

ced

:king::king::king: