Discussion :

[VASAPANCH]

Bonjour,

j'ai développé une petite dll (je suis sous windows) dont j'importe les éléments fonctionnels un à un dans des fonctions C sous postgre. Tout fonctionne très bien pour le moment mais j'ai un soucis lors des appels de commandes système faits par certains des éléments fonctionnels de ma dll.

Ainsi un des éléments fonctionnels de ma dll (importé dans une fonction C sous postgre) est définit ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
PG_FUNCTION_INFO_V1(restruct_voie);
 
DLLIMPORT Datum restruct_voie(PG_FUNCTION_ARGS)
{
 
    system("cd ./RestructVoie");
    system("mkdir rep_test_systeme"); 
    system("My_RestructVoie.BAT");; 
    system("cd ..");
    PG_RETURN_NULL();
 
}

Par défaut je suis dans le répertoire data de postgre; répertoire dans lequel j'ai créé un sous répertoire RestructVoie.

J'attends que le prog 'se déplace' dans 'RestructVoie' puis lance le fichier 'My_RestructVoie' avant de revenir à la racine.

Pour débugger et savoir ou je suis à un instant donné je crée un répertoire de test : 'rep_test_systeme'.

Mon problème est que la commande cd ne fonctionne pas (comme je l'attends) car quoi que je fasse le répertoire 'rep_test_systeme' (que je crée afin de débugger mon programme) est créé à la racine du répertoire 'data' de postgre. Ce qui signifie bien que ma commande "cd ./RestructVoie" ou encore "cd RestructVoie" n'a pas été prise en compte comme je le désire.

J'ai déjà vu des notes concernant des subtilité dans le mécanisme associé à la commande 'cd' mais je ne les retrouve pas.

Quelqu'un aurait-il la solution ?

Merci pour votre lecture !

[JeitEmgie]

Bonjour,

j'ai développé une petite dll (je suis sous windows) dont j'importe les éléments fonctionnels un à un dans des fonctions C sous postgre. Tout fonctionne très bien pour le moment mais j'ai un soucis lors des appels de commandes système faits par certains des éléments fonctionnels de ma dll.

Ainsi un des éléments fonctionnels de ma dll (importé dans une fonction C sous postgre) est définit ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
PG_FUNCTION_INFO_V1(restruct_voie);
 
DLLIMPORT Datum restruct_voie(PG_FUNCTION_ARGS)
{
 
    system("cd ./RestructVoie");
    system("mkdir rep_test_systeme"); 
    system("My_RestructVoie.BAT");; 
    system("cd ..");
    PG_RETURN_NULL();
 
}

Par défaut je suis dans le répertoire data de postgre; répertoire dans lequel j'ai créé un sous répertoire RestructVoie.

J'attends que le prog 'se déplace' dans 'RestructVoie' puis lance le fichier 'My_RestructVoie' avant de revenir à la racine.

Pour débugger et savoir ou je suis à un instant donné je crée un répertoire de test : 'rep_test_systeme'.

Mon problème est que la commande cd ne fonctionne pas (comme je l'attends) car quoi que je fasse le répertoire 'rep_test_systeme' (que je crée afin de débugger mon programme) est créé à la racine du répertoire 'data' de postgre. Ce qui signifie bien que ma commande "cd ./RestructVoie" ou encore "cd RestructVoie" n'a pas été prise en compte comme je le désire.

J'ai déjà vu des notes concernant des subtilité dans le mécanisme associé à la commande 'cd' mais je ne les retrouve pas.

Quelqu'un aurait-il la solution ?

Merci pour votre lecture !

hypothèse :

le process postgres est exécuté sous un compte d'utilisateur qui n'a pas accès à votre dossier RestructVoie…

[VASAPANCH]

en fait c'est le fait de faire appel aux commandes système qui n'est pas bon.
C'est comme si j'ouvrai une console, que j'allais dans mon rep puis que je refermai la console et que je tentais de lancer mon .BAT.

J'ai retrouvé les posts dont je parlais et il préconise d'utiliser la commande c chdir().

Lorsque j'utilise cette commande désormais tou va bien :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
chdir("RestructVoie");
system("FBM_RestructVoie.BAT");

Par contre je n'arrive pas à utiliser les antislash :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

chdir("D:\\Echanges\\mdp_ta_init_lib_c\\RestructVoie");

Mais bon j'ai de quoi cherché donc pour l'instant je vais tagger le post comme résolu quitte à revenir dessus plus tard...

[VASAPANCH]

Il est vrai que j'ai aussi eu à traiter le problème de droit dont tu parles et quelques autres du au fait que je ne suis pas en localhost. D'ailleurs il se peut que je n'ai pas résolu le problème dans les régles de l'art et que mon process soit très peu portable.

Le process postgres s'éxécute avec sous quel utilisateur ? celui définit par le owner de la fonction ?

Merci encore.

[JeitEmgie]

en fait c'est le fait de faire appel aux commandes système qui n'est pas bon.
C'est comme si j'ouvrai une console, que j'allais dans mon rep puis que je refermai la console et que je tentais de lancer mon .BAT.

de fait, on se laisse souvent "avoir"…
la modification du directory courant par "cd" est locale au process lancé par system donc à la sortie de system c'est comme si vous n'aviez rien fait…

pour les antislash essayez donc :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
chdir("D:\\\\Echanges\\\\mdp_ta_init_lib_c\\\\RestructVoie");

[VASAPANCH]

(sauf quand le bien ne suffit pas !)

Bonjour,

j'ai toujours un soucis avec la ligne de commande suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

chdir("D:\\Echanges\\mdp_ta_init_lib_c\\RestructVoie");

j'ai aussi essayé d'utiliser la commande que vous m'avez indiqué mais rien n'y fait.

Je vais prendre le temps d'expliquer le problème un peu bizarre au quel je suis confronté :

1- j'ai donc une dll qui contient différents éléments fonctionnels dont celui particulier pour lequel j'ai indiqué le code dans les messages précédents .
2- j'ai aussi une fonction C dans PostGreSQL pour chacun des éléments de ma dll.
3- lorsque je lance ma fonction 'RestructVoie' depuis PostGre après l'avoir "liée" à l'élément correspondant de la dll, la fonction opére : le programme se rend à l'emplacement indiqué et lance le BAT qui me génére différents fichiers de sortie.
4- le problème est que l'appel de la fonction me renvoie un message d'erreur édité par pgAdmin :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Une erreur s'est produite.
ERROR : could not open relation 1663/50117178/1247

5- Plus surprenant encore : si je me déconnecte, que je me reconnecte, que je lance d'abord une des fonctions référençant un des éléments fonctionnels autre que celui qui léve le message d'erreur tout se passe bien et même pire (ou mieux) si je lance ensuite ma fonction 'RestructVoie' alors non seulement elle opére mais je n'ai plus de message d'erreur !

6- on pourrait se dire alors qu'il suffit de faire précéder l'appel de la fonction bloquante par un appel à une des autres fonctions ("débloquante") ... mais quand on met le tout dans une fonction globale ça affiche le message d'erreur de nouveau.

Drôle de chose !

[VASAPANCH]

Bonjour,

Pour conclure -je l'espère- sur ce post, je pense avoir trouvé d'où vient le problème : initialement lorsque l'on fait appel à une fonction C sous postgre celle si s'éxécute dans le répertoire 'data' de postgre. Si l'on se déplace vers un autre répertoire il est alors conseillé (à mon humble avis) de revenir avant de conclure dans ce répertoire initial.

En effet, je pense que le message d'erreur vient du fait que postgre ne "retrouve pas ces billes" si on sort de la fonction C sans revenir au repertoire 'data' de postgre. Plusieurs raisons m'amènent à penser ça :

1. la première, bien sûr, est qu'après modification de ma dll je n'ai plus de message d'erreur,
   
2. la seconde est que ma fonction C s'éxécutait parfaitement (a priori le problème ne venait donc pas de la fonction),
   
3. la troisième est que c'est bel est bien pgAdmin (à la fin de l'éxécution de ma requête) qui m'indiquait un message d'erreur,
   
4. enfin, ce message indiquait clairement que c'était postgre qui ne retrouvait pas certains de ces fichiers.

Voilà je vais donc tagger ce post comme résolu et je remercie tout ceux qui m'ont aidé car je n'y serais clairement pas parvenu seul.
Merci.

PS : J'aimerais savoir s'il y a des stratégies à adopter lorsque l'on développe des fonction C pour postgre afin de faciliter la portabilité. Initialement je comptais mettre mes dll dans le répertoire lib de postgre et mettre mes ressources dans le répertoire data mais on m'a indiqué qu'il était préférable de mettre ces éléments dans un répertoire extérieur composé de deux sous répertoire : data et lib.
Qu'en pensez-vous ? Faut-il considérer qu'il est "fortement déconseillé" de travailler directement dans les répertoires postgre ?

[JeitEmgie]

Qu'en pensez-vous ? Faut-il considérer qu'il est "fortement déconseillé" de travailler directement dans les répertoires postgre ?

vous n'avez aucune garantie que :
- d'une version à l'autre de postgre la structure de répertoire reste la même…
- qu'un jour des outils postgres ne nettoient pas ces répertoires derrière votre dos…
- que les noms que vous choississez ne rentrent pas un jour en conflit avec d'autres fichiers (si tout le monde fait la même chose : le risque de conflit augmente…) même si en pratique le risque est faible…
- etc.

donc oui : mettre ses fichiers dans des dossiers non explicitement conçus par le "fabricant" pour accueillir des "extensions" est toujours une mauvaise idée… …même si "ça fonctionne" …

(à utiliser donc uniquement si c'est la seule pour résoudre le problème donné… ce qui n'est pas votre cas…)

[VASAPANCH]

Bonjour,

je voulais savoir s'il est possible de définir de nouveaux chemins relatifs (tel que $libdir) pour postgre. Je pense que ce doit être possible en modifiant le fichier de configuration de postgre à la main (?) mais ce n'est sûrement pas très conseillé...

Y aurait-il une fonction qui me permette de faire cela ?

Cordialement,