Rollback / Commit conditionnelles dans une fonction

Bonjour,

Je suis nouveau au forum, je ne connais pas bien postgresql, je souhaite faire un rollback ou commit suivant si j'ai une erreur dans une fonction
ou pas

Exemple : Insertion d'une ligne dans une table si j'ai une exception (erreur) faire rollback si non commit
et cela dans une fonction complexe.

Mais j'ai compris que dans une fonction on peut pas faire rollback ou commit, quelqu'un peut m'aider à savoir comment je pourrai poser une condition
pour valider l'insertion (Commit) ou l'annuler par Rollback suite à l’exécution de la fonction (je suis obligé de créer une fonction pour gérer un ensemble des tables ) ,

Merci de votre aide

bonjour,

C'est au traitement principal de savoir à quel moment les données sont cohérentes et qu'il faut "commiter" la transaction.
En effet, une fonction peut ne réaliser qu'une partie des modifications en base pour le traitement.
Il serait incohérent de valider cette partie des modifications alors que d'autres mises à jour sont faites par appel à d'autres fonctions ou procédures stockées ou en directement par requête et ne seront éventuellement pas commitées car tomberont en erreur.
De plus, une même fonction pouvant être appelée par plusieurs traitements, ce qui est acceptable pour l'un est peut être une erreur grave pour l'autre.
Raison de plus pour gérer les commit/rollback dans le traitement principal ;)

Au sujet du "comment" il faut donc réaliser l'ensemble des opérations de mise à jour directement ou par appel à des fonctions ou procédures, puis, si tout s'est bien passé, commiter l'ensemble.
Si au contraire, l'une des étapes de mise à jour produit une erreur grave, alors on fait le rollback et on ignore les MàJ suivantes.
Tout ça dans le traitement principal.

Le détail des instructions liées aux transactions est ici : https://www.postgresql.org/docs/9.1/sql-begin.html

Citation:

---

Envoyé par escartefigue

bonjour,

C'est au traitement principal de savoir à quel moment les données sont cohérentes et qu'il faut "commiter" la transaction...

---

Hélas ce sont les limites de fonctionnement de PostGreSQL qui n'a jamais implémenté la notion de Procédure stockée !

Tous les autres SGBDR, permettent de piloter les transactions comme on le souhaite dans toutes les routines (procédures, declencheurs...) exception faite des fonctions dont le principe est d'être utilisé indirectement par une requête, une procédure, un trigger une vue....

PostGreSQL ayant commis les stupides conneries de :

• confondre fonction et procédures
• et de ce fait interdire que ces fonctions puissent avoir leur propre autonomie transactionnelles !

A +

Citation:

---

Envoyé par Wha001

Mais j'ai compris que dans une fonction on peut pas faire rollback ou commit

---

Bonjour, on peut mais il faut que le client soit en autocommit.
L'explication: https://medium.com/@FranckPachot/pos...s-9b57cb909067

Citation:

---

Envoyé par SQLpro

Hélas ce sont les limites de fonctionnement de PostGreSQL qui n'a jamais implémenté la notion de Procédure stockée !

Tous les autres SGBDR, permettent de piloter les transactions comme on le souhaite dans toutes les routines (procédures, declencheurs...) exception faite des fonctions dont le principe est d'être utilisé indirectement par une requête, une procédure, un trigger une vue....

PostGreSQL ayant commis les stupides conneries de :

• confondre fonction et procédures
• et de ce fait interdire que ces fonctions puissent avoir leur propre autonomie transactionnelles !

A +

---

Encore une fois, que d'affirmations non vérifiées !
Et que d'insultes inutiles !

PostgreSQL a implémenté les transactions dans les procédures stockées à partir de la version 11.
Il n'y a vraiment que les butés qui ne changent décidément pas !!!

Citation:

---

Envoyé par ced

Encore une fois, que d'affirmations non vérifiées !
Et que d'insultes inutiles !

---

Je ne voit pas ou tu voit des insultes...

Citation:

---

PostgreSQL a implémenté les transactions dans les procédures stockées à partir de la version 11.
Il n'y a vraiment que les butés qui ne changent décidément pas !!!

---

De manière très incomplète comme le souligne Pachot....
1) pas de possibilité de transaction explicite en mode non autocommit (bug ?...)
2) pas de possibilité de changer le niveau d'isolation en cours d'exécution de la transaction
3) pas de transactions imbriquées
4) pas de transactions "autonomes" à la oracle (fonctionnalité à mon sens parfaitement idiote !, mais c'est un autre débat)
5) pas de possibilité de définir différents niveaux d'isolation pour les différentes tables d'une même requête

C'est donc loin d'être complet en plus d'être bugué !

A +

Citation:

---

Envoyé par SQLpro

Je ne voit pas ou tu voit des insultes...

---

Citation:

---

Envoyé par SQLpro

les stupides conneries

---

Rappel de la définition d'une insulte, dixit le Larousse : "Parole ou acte qui offense". C'est là où je vois des insultes.
Mais c'est peut-être votre langage habituel...?

Citation:

---

Envoyé par SQLpro

PostGreSQL qui n'a jamais implémenté la notion de Procédure stockée !

---

Citation:

---

Envoyé par SQLpro

De manière très incomplète

---

Alléluia ! Donc, vous reconnaissez que c'est implémenté, contrairement à votre message précédent... On progresse...

Citation:

---

Envoyé par SQLpro

C'est donc loin d'être complet en plus d'être bugué !

---

Allons ! Un habitué de Microsoft comme vous devrait savoir que ce n'est pas un bug, "it's a feature !"...
D'ailleurs, le comportement mis en avant par pachot ne vient pas du moteur, mais des clients (psql et jdbc).

Alors certes, on peut toujours demander des fonctionnalités supplémentaires, et l'implémentation des transactions dans les procédures dans PostgreSQL est loin d'être complète, mais il est faux d'affirmer de manière péremptoire que ça n'a jamais été fait.

À bon entendeur...

Bonjour,

Merci pour vos retours, j'ai réussi à trouver une solution pour appliquer le rollback si besoin en utilisant les exceptions dans les fonctions
que j'utilise

Merci Encore