Vous n'êtes pas identifié(e).
Pages : 1
Merci beaucoup Marc,
C'est bien ce qu'il me semblait cependant, ca pose pas mal de problème pour le portage. Comment faire pour créer une fonction qui permettent de modifier une variable externe à la fonction. On va être obligatoirement obliger de modifier le source du programme qui s'appuie sur la fonction PostgreSQL traduite pour récupérer la valeur du paramètre en sortie de la fonction et l'assigner à la variable du programme. Si tu as des solutions, hesite pas à me les transmettre, merci beaucoup.Bonne journée.
Désolé Gleu si je me suis mal exprimé, je te donne un exemple Oracle.
Procédure ORACLE :
CREATE OR REPLACE FUNCTION TEST(A IN NUMBER, B IN OUT NUMBER) RETURN NUMBER IS
C NUMBER(3);
BEGIN
B := A;
C := A + B;
RETURN C;
END;
DECLARE
A1 NUMBER(3) := 10;
B1 NUMBER(3) := 20;
C1 NUMBER(3)
BEGIN
C1 := TEST(A1,B1);
DBMS_OUTPUT.PUT_LINE(A1 || ' ' || B1 || ' ' || C1);
END;
Dans cette fonction, B est passé en entrée/sortie.En d'autres termes, lors de l'affichage de B1, B1 ne sera plus égale à 20 mais à A soit 10. Nous avons donc une variable B1 qui a été passé en paramètre de la fonction TEST et qui se retrouve modifier après son appel.
Maintenant, j'aimerais faire une traduction de cette procédure sous PostgreSQL. Comment ferez-tu?
J'ai cette solution :
CREATE OR REPLACE FUNCTION TEST(A IN INTEGER, B INOUT INTEGER,C OUT INTEGER) RETURNS RECORD AS $$
BEGIN
B := A;
C := A + B;
END;
$$ language 'plpgsql';
Cependant le comportement n'est pas du tout le même que celui d'ORACLE puisque ma fonction au lieu de renvoyer 1 valeur soit la valeur de C, elle renvoie deux valeurs, la valeur de C et celle de B.Les concepts de INOUT et OUT ne sont pas les mêmes sur PostgreSQL. En effet, sous Oracle il suffit de mettre deux variables en entrée de la procédure et on récupère la valeur de C tout en ayant la variable B1 qui a été modifier durant la fonction. Sur PostgreSQL, on récupère la valeur de C et de B.
Sera t'il possible de renseigner le paramètre INOUT B de ma fonction avec une variable et si cela est possible est ce qu'après l'appel de la procédure ma variable aura été modifié?
Bonjour tout le monde,
Je suis actuellement en train de faire un portage de Oracle sur PostgreSQL cependant je me suis aperçu d'un problème assez gênant. En effet, la notion INOUT qui est présent sous PostgreSQL ne représente pas la même notion que celle d'ORACLE. Sur ORACLE, cela signifie qu'on passe le paramètre par référence. En d'autres termes, lors de l'appel de la fonction, on renseigne le paramètre avec une variable externe à la fonction. Cette variable peut être modifier par la fonction.Si tel est le cas, la variable n'aura plus la même valeur en sortant de la fonction.
Sur PostgreSQL, ceci est totalement différent. En effet, lorsque l'on passe un paramètre en E/S sur PostgreSQL, cela sert juste à éviter de déclarer une variable en entrée et une variable en sortie quand elles sont du même type.
Exemple :
CREATE FUNCTION incremente(INOUT int4) AS
$$
BEGIN
$1 = $1 + 1;
END;
$$ LANGUAGE plpgsql;
metier=# SELECT incremente(5);
incremente
----------------
6
(1 ligne)
Je post donc ce sujet afin de savoir si ce que j'ai dit précédemment est vrai. Si tel est le cas, quelles solutions sont envisageable pour palier à ce problème.
Bonjour tout le monde,
Le script de migration ora2pg qui permet une migration de ORACLE vers Postgre gère t'il la migration de procédure stockée contenant des instructions GOTO?
Merci d'avance. Bonne journée.
salut Gleu,
Je sais pertinemment que le GOTO est une mauvaise pratique cependant je suis stagiaire et ce n'est pas moi qui est mise en place cela donc bon je me retrouve avec cette fonctionnalité qui me bloque pour la migration. Quand tu as plus de 500 procédures stockées avec des GOTO, beh je me vois mal aller tout rechanger. Quand à la possibilité de rajouter la fonctionnalité d'un GOTO, il n'y pas besoin que j'attende forcement le prochain patch il suffit que je me fasse ma propre version. Une fois la fonctionnalité implémentée, je compile le source et j'ai ma distribution de prête. Sinon sur la théorie je suis tout à fait d'accord avec toi. Le GOTO est selon moi une mauvaise pratique cependant des vieux systèmes qui l'utilisait à l'époque lorsqu'il était à la mode n'ont pas changer et désormais il faut que je fasse avec. Cependant je te remercie pour ta réponse et espère trouver une personne qui a déjà toucher au source pour me confirmer si oui ou non cela est réalisable. Dans le cas contraire et bien il faudra que je traduise tous les GOTO en boucle sachant que dans certains cas la traduction reste impossible. La migration s'annonce plutôt ardu. Merci à tous bonne journée.
Bonjour tout le monde,
Je suis actuellement stagiaire et je dois migrer une base de donnée Sybase vers un SGBD Open Source. J'ai donc choisi PostgreSQL puisque c'est le SGBD qui me parait le plus adapté pour diverses raisons. Cependant j'ai un soucis majeur qui était aussi présent sur les autres SGBD Open Source. En effet, l'instruction GOTO est absente or elle m'est indispensable pour mener à terme ma migration. J'aimerais donc trouver une personne( ou un génie ) capable de modifier le code source pour inclure cette fonctionnalité dans le langage PL/pgSQL. Merci d'avance.
Pages : 1