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

Re: Migration SQL Serveur 2008 vers PostgreSQL

From: Marc Cousin <cousinmarc(at)gmail(dot)com>
To: pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: Migration SQL Serveur 2008 vers PostgreSQL
Date: 2012-01-04 13:11:04
Message-ID: 5110658.2sxnkP6ErO@marco-dalibo (view raw or flat)
Thread:
Lists: pgsql-fr-generale
On Wednesday 04 January 2012 12:00:16 Jehan-Guillaume  de Rorthais wrote:
> On 04/01/2012 09:59, F. BROUARD / SQLpro wrote:
> > Bonjour,
> > 
> > [...]
> > - au niveau des procédures stockées (en fait elle n'existent pas, seule
> > des fonctions atomiques existant dans PG) ce qui pose problème si des
> > transactions sont encapsulées dans les PS.
> 
> Pourriez-vous détailler un peu ce point ? Ce que je comprends ici c'est
> que PL/PgSQL ne supporte pas les sous transactions, j'imagine qu'il doit
> y avoir une subtilité qui m'échappe. Par exemple (en 9.1.2):
> 
>   test=# CREATE TABLE test (i int);
>   CREATE TABLE
>   test=# CREATE OR REPLACE FUNCTION public.test(val1 integer, val2
> integer, subcommit boolean)
>    RETURNS SETOF test
>    LANGUAGE plpgsql
>   AS $function$
>   BEGIN
>           INSERT INTO test VALUES(val1);
>           BEGIN
>                   INSERT INTO test VALUES(val2);
>                   IF NOT subcommit THEN
>                           RAISE SQLSTATE '40000';
>                   END IF;
>                   EXCEPTION WHEN SQLSTATE '40000' THEN
>                           RAISE NOTICE $$paramètre subcommit à 'f',
> rollback val2=%.$$, val2;
>           END;
> 
>           RETURN QUERY SELECT * FROM test;
>   END
>   $function$
>   ;
>   CREATE FUNCTION
>   test=# SELECT * FROM test(1,2,'t');
>    i
>   ---
>    1
>    2
>   (2 lignes)
> 
>   test=# SELECT * FROM test(3,4,'f');
>   NOTICE:  paramètre subcommit à 'f', rollback val2=4.
>    i
>   ---
>    1
>    2
>    3
>   (3 lignes)
> 
> 
> Et du coup, ce même code semble aussi entrer en conflit avec votre point
> « 2 - Une gestion des transactions "curieuse". » de votre documentation
> « les limites des migrations vers PG », je cite particulièrement:
>   * « il est impossible de gérer une transaction à l'intérieur du code
> d'une fonction postGreSL. »
>   * « En sus ce n'est pas parce que il y a une erreur que l'on doit
> considérer automatiquement que la transaction doit être annulé. C'est en
> principe l'auteur du code et lui seul qui doit décider de la règle de
> gestion et non le SGBDR ! »
> 
> Bref, une subtilité m'échappe là dedans.

Il ne parle pas de sous transactions mais de transactions autonomes. Elles 
permettent d'avoir une transaction qu'on peut valider (ou non) indépendamment 
de la transaction dans laquelle la fonction/le trigger a été appelée. 

Par exemple, c'est intéressant pour maintenir une table de log: avec un 
trigger, sous PG, on ne peut pas tracer dans une table de log le fait que 
quelqu'un a tenté un update sur une table et l'ait annulé. Avec une 
transaction autonome, on peut.

In response to

pgsql-fr-generale by date

Next:From: Dimitri FontaineDate: 2012-01-04 15:36:07
Subject: Re: Migration SQL Serveur 2008 vers PostgreSQL
Previous:From: Guillaume LelargeDate: 2012-01-04 11:04:45
Subject: Re: Migration SQL Serveur 2008 vers PostgreSQL

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