Vous n'êtes pas identifié(e).
Pages : 1
Bonjour
c'est une remarque plus qu'une question, un truc qui m'a surpris : je me suis aperçu que lorsqu'une contrainte CHECK renvoie NULL, il laisse passer toutes les valeurs
soit un cas simple
CREATE TABLE toto (
titi INTEGER PRIMARY KEY,
tata INTEGER
CHECK (tata = pipot(titi))
);
Je m'étais retrouvé avec des données dans la table toto qui selon moi auraient dû être rejetées par le CHECK. En cherchant, j'ai découvert que j'avais fait une erreur dans pipot(titi), qui renvoyait null dans certains cas...donc la vérification tata = pipot(titi) renvoyait forcément aussi null
je m'attendais à ce que dans ce cas toute insertion dans toto soit rejetée à cause de cette contrainte CHECK non vérifiée, mais en fait au contraire il laisse tout passer
Autrement dit, si CHECK renvoie NULL l'insertion est acceptée, c'est uniquement quand CHECK renvoie FALSE que c'est rejeté
Il faut donc veiller à ce que CHECK renvoie toujours TRUE ou FALSE, et jamais NULL, au risque de se retrouver avec des insertions non voulues
un peu surprenant quand même...
Hors ligne
Oui, mais c'est dans la doc 
CHECK ( expression )
The CHECK clause specifies an expression producing a Boolean result which new or updated rows must satisfy for an insert or update operation to succeed. Expressions evaluating to TRUE or UNKNOWN succeed.
C'est aussi ce que dit la norme SQL. C'est d'ailleurs pour ça que c'est comme ça dans Postgres.
Pas que ça me semble à moi non plus forcément logique d'accepter une donnée dont la contrainte check répond 'je ne sais pas', mais c'est la norme
Marc.
Hors ligne
...et on ne discute pas avec la norme
bon, on va dire qu'ils ont fait ça pour nous motiver à écrire des contraintes CHECK bien propres qui ne renvoient jamais null
en tout cas merci, vous avez décidément réponse à tout !
Hors ligne
Si seulement…
Marc.
Hors ligne
Pages : 1
