Comment empêcher la suppression de la première ligne de la table (PostgreSQL)?

Question

Est-il possible d'empêcher la suppression de la première ligne de la table côté PostgreSQL?

J'ai une table de catégories et je veux empêcher la suppression de la catégorie par défaut car cela pourrait casser l'application. Bien sûr, je pourrais facilement le faire dans le code de l'application, mais il serait beaucoup mieux de le faire dans la base de données.

Je pense que cela a quelque chose à voir avec les règles relatives à l'instruction de suppression, mais je n'ai rien trouvé de proche de mon problème dans la documentation.

Answer 1

La meilleure façon de procéder consiste à créer un déclencheur de suppression sur cette table. Fondamentalement, vous devrez écrire une procédure stockée pour vous assurer que cette catégorie 'par défaut' existera toujours, puis l'appliquer à l'aide d'un événement trigger ON DELETE sur cette table. Un bon moyen de le faire consiste à créer un déclencheur par ligne garantissant que, lors d'événements DELETE, la ligne de catégorie 'par défaut' ne sera jamais supprimée.

Veuillez consulter la documentation de PostgreSQL sur les déclencheurs et les procédures stockées:

http://www.postgresql.org/docs/8.3 /interactive/trigger-definition.html

http://www.postgresql.org/docs/8.3/interactive /plpgsql.html

Ce wiki contient également de précieux exemples:

http://wiki.postgresql.org/wiki/A_Brief_Real-world_Trigger_Example

Answer 2

Vous aviez raison de penser au système de règles. Voici un lien vers un exemple correspondant à votre problème. C'est encore plus simple que les déclencheurs:

create rule protect_first_entry_update as
  on update to your_table
  where old.id = your_id
  do instead nothing;
create rule protect_first_entry_delete as
  on delete to your_table
  where old.id = your_id
  do instead nothing;

Certaines réponses manquent un point: la mise à jour de la ligne protégée doit également être restreinte. Sinon, on peut d'abord mettre à jour la ligne protégée de sorte qu'elle ne réponde plus au critère de suppression interdit, puis supprimer la ligne mise à jour car elle n'est plus protégée.

Answer 3

Vous souhaitez définir un déclencheur sur la table, BEFORE DELETE. Lorsque vous essayez de supprimer la ligne (correspond à PK ou utilisez une colonne booléenne "protect" distincte), RAISE une exception.

Je ne connais pas bien la syntaxe de PostgreSQL, mais cela ressemble à voici comment vous le feriez:

CREATE FUNCTION check_del_cat() RETURNS trigger AS $check_del_cat$
    BEGIN            
        IF OLD.ID = 1 /*substitute primary key value for your row*/ THEN
            RAISE EXCEPTION 'cannot delete default category';
        END IF;

    END;
$check_del_cat$ LANGUAGE plpgsql;

CREATE TRIGGER check_del_cat BEFORE DELETE ON categories /*table name*/
    FOR EACH ROW EXECUTE PROCEDURE check_del_cat();

Answer 4

Vous pourriez avoir une ligne dans une autre table (appelée par défaut) référençant la catégorie par défaut. La contrainte FK ne permet pas la suppression de la catégorie par défaut.

Answer 5

Gardez à l’esprit le fonctionnement des déclencheurs. Ils se déclencheront à chaque ligne que votre instruction delete supprimera. Cela ne signifie pas que vous ne devez pas utiliser de déclencheurs, mais gardez cela à l'esprit et surtout testez vos scénarios d'utilisation et assurez-vous que les performances répondent aux exigences.

Devrais-je utiliser une règle ou un déclencheur?

D'après les documents officiels: "Pour les choses qui peuvent être mises en œuvre par les deux, le mieux dépend de l'utilisation de la base de données. Un déclencheur est déclenché pour chaque ligne affectée une fois. Une règle manipule la requête ou génère une requête supplémentaire. Par conséquent, si plusieurs lignes sont affectées dans une instruction, une règle émettant une commande supplémentaire sera probablement plus rapide qu'un déclencheur appelé pour chaque ligne et devant exécuter ses opérations plusieurs fois. Toutefois, l’approche de déclenchement est beaucoup plus simple sur le plan conceptuel que l’approche par règle, et il est plus facile pour les novices de bien comprendre les choses. "

Voir la documentation pour plus de détails.
http://www.postgresql.org/docs/8.3/interactive/ rules-triggers.html