Skip site navigation (1) Skip section navigation (2)

Re: Migration SQL Serveur 2008 vers PostgreSQL

From: "F(dot) BROUARD / SQLpro" <sqlpro(at)club-internet(dot)fr>
To: pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: Migration SQL Serveur 2008 vers PostgreSQL
Date: 2012-01-05 08:59:52
Message-ID: 4F056688.7070000@club-internet.fr (view raw or flat)
Thread:
Lists: pgsql-fr-generale
Voici un exemple de transactions infaisable sous PG :

CREATE TABLE T1 (C1 INT);
CREATE TABLE T2 (C2 INT CHECK (C2 > 0))
CREATE TABLE T3 (C3 INT);
GO

CREATE PROCEDURE P_INSERT_TRANSACTION
        @VAL1 INT
AS
BEGIN
    -- demarrage d'une transaction
    BEGIN TRANSACTION;
    -- test de validité
    BEGIN TRY
       INSERT INTO T1 VALUES (@VAL1);
       INSERT INTO T2 VALUES (@VAL1);
       COMMIT TRANSACTION;
    END TRY
    -- en cas d'erreur
    BEGIN CATCH
       IF XACT_STATE() <> 0
          ROLLBACK TRANSACTION;
       INSERT INTO T3 VALUES (@VAL1);
    END CATCH
END;
GO

-- permier test réussi :
EXECUTE P_INSERT_TRANSACTION 1;
GO

-- resultats :
SELECT * FROM T1;
SELECT * FROM T2;
SELECT * FROM T3;

C1
-----------
1

C2
-----------
1

C3
-----------

-- second test échec :
EXECUTE P_INSERT_TRANSACTION -1
GO

-- resultats :
SELECT * FROM T1;
SELECT * FROM T2;
SELECT * FROM T3;


C1
-----------

C2
-----------

C3
-----------
-1

La procédure insère dans les tables T1 et T2 dans la cadre d'une 
transaction et, en cas de viol de la contrainte CHECK, annule la 
transaction et insère dans la table T3...

En sus PG ne permet pas de piloter le niveau d’isolation des 
transactions de manière dynamique..

Exemple :

CREATE PROCEDURE P_INSERT_TRANSACTION
        @VAL1 INT
AS
BEGIN
    -- demarrage d'une transaction
    BEGIN TRANSACTION;
    -- test de validité
    BEGIN TRY
--> modification du niveau d'isolation
       SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
       INSERT INTO T1 VALUES (@VAL1);
       INSERT INTO T2 SELECT * FROM T1;
       COMMIT TRANSACTION;
--> modification du niveau d'isolation
       SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
    END TRY
    -- en cas d'erreur
    BEGIN CATCH
       IF XACT_STATE() <> 0
          ROLLBACK TRANSACTION;
       INSERT INTO T3 VALUES (@VAL1);
    END CATCH
END;
GO

Les transaction imbriquées, sont une autre difficultés (les sous 
transactions cela n'existe pas, car par nature une transaction est 
atomique !!!)

A lire :

http://sqlpro.developpez.com/cours/sqlserver/transactions-imbriquees/

Le 04/01/2012 16:36, Dimitri Fontaine a écrit :
 > "Jehan-Guillaume (ioguix) de Rorthais"<ioguix(at)free(dot)fr>  writes:
 >> Bref, une subtilité m'échappe là dedans.
 >
 > Ton exemple fonctionne parce que tu as pu faire un ROLLBACK à
 > l'intérieur de ton traitement tout en faisant un COMMIT global.
 >
 > Essaye maintenant de faire un ROLLBACK global en ayant pu faire un
 > COMMIT du traitement interne…  avec une procédure tu peux.
 >
 > Évidemment du coup une fonction est invoquée de la même manière qu'un
 > Utility Statement, avec la syntaxe dédiée CALL.  Ce que tu peux très
 > bien faire dans un trigger, échouer à faire l'opération qui a déclencher
 > le trigger et avoir commité le traitement réalisé dans le CALL.
 >
 > Il existe peut être d'autres syntaxes et d'autres modes de
 > fonctionnements, à vérifier.
 >
 > Sous PostgreSQL nous n'avons pas de procédures au sens standard SQL,
 > nous n'avons que les fonctions, qui sont utilisées au sein de requêtes,
 > et auxquelles échappent complètement la notion de transaction.
 >
 > La raison pour laquelle nous n'avons pas encore de procédures standard
 > est à mon avis double : c'est assez compliqué à faire « correctement »
 > pour que personne n'y ait encore vu un intérêt (financier, par exemple)

J'aime beaucoup ce genre de commentaires...
Pensez-vous sincèrement que ce que fait oracle, MS SQL Server, IBM DB2 
ou Sybase ASE nativement et que ne peut pas faire PG soit un gadget 
imbécile et inutile ?

je croyais les gens de 2ndQuadrant un peu plus ouvert... Mais sans doute 
me trompais-je !

 > assez fort pour se mettre au boulot.
 >
 > Nous attendons tous avec impatience que ce moment se présente :)

A +

-- 
Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66
Le site sur le langage SQL et les SGBDR  :  http://sqlpro.developpez.com
Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************


In response to

Responses

pgsql-fr-generale by date

Next:From: Ronan DunklauDate: 2012-01-05 09:40:08
Subject: Re: Migration SQL Serveur 2008 vers PostgreSQL
Previous:From: Cousin FlorenceDate: 2012-01-05 08:52:00
Subject: RE : Migration SQL Serveur 2008 vers PostgreSQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group