Re: Migration SQL Serveur 2008 vers PostgreSQL

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.