Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous !
Je suis un petit nouveau dans tout ce qui touche à PostgreSQL et j'ai pour objectif de réaliser une application communiquant avec ce SGBD en C++.
Comme l'ensemble du code de l'application sera écrit en C++ pure, j'aimerais éviter d'avoir à utiliser l'API standard de PostgreSQL qui nous "oblige" à écrire du C.
Après quelques recherches, je suis tombé sur libpqxx (http://pqxx.org/development/libpqxx/) qui se dit être la bibliothèque officielle de PostgreSQL en C++, or, bien que cette lib soit multiplate-forme, l'auteur semble avoir totalement délaissé les utilisateurs tournant sous Windows et j'éprouve beaucoup de difficultés à la compiler avec le compilateur de Visual Studio 2011.
Je voudrais donc juste savoir si quelqu'un ici a déjà réussi à compiler libpqxx sous Windows ?
Merci d'avance pour votre aide !
Hors ligne
Je ne sais pas pour les autres. Je ne l'ai jamais compilé, que ce soit sous Windows ou sous Linux. Je fais pas mal de développements pour pgAdmin, donc en C++, mais on ne passe par par libpqxx. On utilise directement la libpq car on peut en utiliser toute la puissance.
Guillaume.
Hors ligne
Merci pour ta réponse !
En principe, on peut tout aussi bien utiliser la puissance de libpq avec libpqxx puisqu'il s'agit, pour moi, d'une simple surcouche permettant l'utilisation de la syntaxe propre au C++. libpq est donc nécessaire pour que libpqxx puisse fonctionner et donc si jamais des fonctionnalités offertes par libpq ne sont pas exploité avec libpqxx, on peut toujours utiliser la lib de base !
Personne n'a utilisé libpgxx sur Windows ?
Hors ligne
Il y a une couche supplémentaire, donc forcément des lenteurs et des bugs supplémentaires. Pas forcément une tripoté, mais plus quand même.
Guillaume.
Hors ligne
Rebonjour !
Je suis toujours en train d'essayer de compiler libpqxx n'ayant toujours pas réussi. Ceci étant dit, je m'approche du but puisqu'il me manque seulement quelques fichiers pour que la compilation se passe correctement. Ces fichiers sont:
Debug/
libpqd.dll
libpqddll.dll
libpqddll.lib
Release/
libpqdll.dll
libpqdll.lib
Je suppose donc qu'il faut que je compile à la main PostgreSQL puisque je me suis contenté de l'installer avec l'installateur fourni sur le site.
Or, je bloque encore une fois puisque cette fois-ci, la compilation de PostgreSQL, il ne trouve pas .\Release\libpq.dll.manifest.
Est-ce que quelqu'un a déjà compilé la version 9.1.3 de PostgreSQL à partir des sources sous Windows 7 avec MSVC11 ?
Merci encore pour votre aide !
Hors ligne
Oui, j'ai compilé PostgreSQL 9.1.3 sous Windows. J'utilise l'outil disponible dans le répertoire src/tools/msvc. Un outil appelé build qui a tout fait tout seul. Le mieux est de suivre la doc : http://docs.postgresql.fr/9.1/install-w … ndows-full
Guillaume.
Hors ligne
Merci pour ta réponse encore une fois !
Malheureusement, et pour une raison que j'ignore, il ne connait pas la commande "vcbuild", ce qui l'empêche de construire quoique ce soit...
Pourtant, j'ai bien pris soin de lancer le script build.bat avec l'environnement de Visual Studio 2011 (en prenant l'invite de commande fournie par Visual Studio).
J'ai quand même chercher pour voir où pouvait se trouver un éventuel binaire nommé "vcbuild.exe" dans les dossiers d'installation de Visual Studio, afin de l'ajouter au PATH, mais je n'ai malheureusement rien trouvé. Pourtant, il devrait être présent puisque j'ai installé Visual Studio, non ?
Merci encore.
Hors ligne
Le problème pourrait bien venir de la version de VisualStudio. Comme l'indique le document dont j'ai donné l'URL plus tôt, PostgreSQL supporte les compilateurs de Visual Studio 2005™ et Visual Studio 2008™. Pas au-dessus. La version 9.2 devrait supporter Visual Studio 2010. Quant à Visual Studio 2011, ça ne sera pas pour tout de suite 
Guillaume.
Hors ligne
Ça ne devrait pas poser de problème puisque j'ai aussi la version 2010 de Visual Studio installée sur ma machine et la 2008 est prête à être installée si besoin est. Ce que je souhaite, c'est simplement généré les fichiers qu'il manque, peut importe le compilateur finalement.
Hors ligne
Vous dites avoir lancé le script avec l'environnement Visual Studio 2011. Faites-le mais avec l'environnement Visual Studio 2008.
Guillaume.
Hors ligne
En principe, on peut tout aussi bien utiliser la puissance de libpq avec libpqxx puisqu'il s'agit, pour moi, d'une simple surcouche permettant l'utilisation de la syntaxe propre au C++. libpq est donc nécessaire pour que libpqxx puisse fonctionner et donc si jamais des fonctionnalités offertes par libpq ne sont pas exploité avec libpqxx, on peut toujours utiliser la lib de base !
A condition de le faire dans une connexion à part, ce qui en limite beaucoup l'intérêt, Car il y a une étanchéité explicite entre libpqxx et libpq.
Extrait de la FAQ: http://pqxx.org/development/libpqxx/wiki/FaqFeatures
For my program I need to access some C-level libpq structure that libpqxx hides from me. Can you add a member function that lets me do this?
Generally, no. If you require support for specific high-level functionality, the better solution is usually to build it into the abstraction layer rather than to break the abstraction layer open like this.
Also, the isolation that the abstraction layer provides allows libpqxx to do things like automatic connection recovery. Such things can be impossible if the library does not have full and unique control over the underlying C-level structures, or in other cases they might lead to subtle and complex bugs in your program.
Personnellement, ayant besoin de C++ et peu emballé par l'API de libpqxx et certains de ses choix de conception, j'ai choisi il y a longtemps de faire ma propre surcouche ( http://manitou-mail.org/pgstream/overview.html ) qui permet de mélanger C et C++ , mais surtout avec une API plutôt du style d'OTL pour oracle ( http://otl.sourceforge.net ) dont l'élégance m'avait impressionné.
Et aujourd'hui pour PG il y a aussi libpqtypes en C ( http://libpqtypes.esilo.com/ ) qui est à considérer pour se simplifier le code.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Merci pour ta réponse dverite !
Est-ce que tu peux m'en dire plus sur les choix de conception de libpqxx que tu n'as pas aimé ? (mis à part le défaut cité plus haut)
Sinon, t'as surcouche semble être intéressante, mais j'ai l'impression que tout comme libpqxx, tu ne proposes rien en ce qui concerne sa compilation sur des systèmes Windows, et j'ai malheureusement besoin d'une lib qui soit multiplate-forme. J'ai bien tenté de la compiler avec MinGW, mais après avoir exécuté le configure, lorsque j'essaye de lancer un "make", il me dit qu'il n'y a rien à faire pour "all" ni pour "all-am".
Quant à libpqtypes, ça reste du C, mais je vais y jeter un oeil !
Merci encore !
Hors ligne
Est-ce que tu peux m'en dire plus sur les choix de conception de libpqxx que tu n'as pas aimé ? (mis à part le défaut cité plus haut)
Ok, voici quelques éléments de réponse:
Un inconvénient concret est qu'on ne peut pas exécuter des commandes sql sans instancier d'abord une transaction, alors que postgresql lui-même ne l'impose pas (non seulement il ne l'impose pas mais dans de rares comme CREATE DATABASE, il l'interdit. A ce jour il me semble qu'il n'y a tjrs pas de moyen de faire un create database avec libpqxx).
En plus le design pattern suggéré des functors pour les transactions me parait trop loin de la logique classique d'encapsulation, et sert surtout à "résoudre" un pb (la perte de connexion), qui à mon avis est hors sujet.
La lib ne gère pas du tout le format binaire. L'intérêt du binaire est discutable pour le tout venant, mais pour les champs bytea de taille significative, c'est dommage.
D'une manière générale, le niveau d'abstraction de l'API me parait trop élevé là où ça ne m'intéresse pas vraiment et pas assez là où ça m'intéresserait.
Trop: parce que quand on connait déjà les idiomes postgresql et qu'on sait à quoi on veut arriver au niveau SQL, on se retrouve à décortiquer l'API de haut en bas pour trouver derrière quelle classe c'est caché et à quel niveau de la hiérarchie il faut opérer. Parfois c'est dur à comprendre: pour les prepared statements par exemple, la méthode pour typer les paramètres m'a paru incompréhensible, et aucun exemple ni dans la doc ni dans le tutoriel.
En revanche, peu d'abstraction pour les manipulations de données échangées entre client et serveur et la gestion de type. On utilise esc(), to_string(), from_string() pour encoder/décoder, et là on se croirait presque en C. Cette partie-là me parait décevante parce qu'on peut faire mieux en C++. Rien non plus pour gérer les tableaux ou les types composites ni en entrée ni en sortie.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Sinon, t'as surcouche semble être intéressante, mais j'ai l'impression que tout comme libpqxx, tu ne proposes rien en ce qui concerne sa compilation sur des systèmes Windows
J'ai sous le coude un mail avec un patch d'un utilisateur pour VS2010 qu'il faudrait que j'intègre.
Je crois qu'il y a juste une allocation dynamique de tableau dans la pile (=extension gcc) qui nécessite un remplacement de code, le reste étant surtout du préprocesseur. Rien de bien méchant.
Pour ce qui est de la compilation à part, la manière la plus simple de l'exploiter est de copier le .h et .cpp dans son propre projet sans même chercher à en faire une lib, ça va tout à fait avec le côté basique et léger de la surcouche.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Merci beaucoup encore une fois pour tes réponses !
Je viens à peine de réussir à compiler la libpqxx et je commence à hésiter à l'utiliser finalement plutôt que celle que tu as développées, car elle m'a l'air très bien faite.
Comme j'ai encore un peu de mal à me décider (et que je m'étais promis hier de rester sur libpqxx quoiqu'il arrive maintenant 
), j'aurais juste voulu savoir ce qu'il te restait encore des à développer pour pgstream (j'ai cru comprendre qu'elle était encore en version bêta).
Hors ligne
Beta c'est subjectif. Ici c'est parce qu'il n'y a pas eu vraiment de stress-test sur ce code.
Sinon, pas de nouvelles fonctionnalités prévues à court terme. Ca m'intéresserait beaucoup d'intégrer libpqtypes, mais je n'ai pas assez de temps pour le faire.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Je viens de tenter de compiler pgstream et je me confronte effectivement à 2 problèmes.
Le premier concerne "snprintf", mais même en incluant le header qui va bien (cstdio), le compilateur semble ne pas trouver cette fonction. En revanche, il trouve "_snprintf" qui est une fonction disponible dans stdio.h, que tu as déjà inclut. Est-ce que ces 2 fonctions ont vraiment le même comportement ?
Le deuxième est à propos de l'allocation d'un tableau avec une taille dynamique. D'après ce que j'ai compris, cette pratique est supportée depuis la norme C99 du C, mais le compilateur de Visual Studio ne semble pas l'autoriser pour une raison inconnue. J'ai donc dû modifier légèrement le code, mais j'aurais besoin de tes conseils puisque j'ai forcément besoin d'une taille "max" qui puisse être utilisée à la place de "m_vars.size()" et je n'ai absolument aucune idée de ce que ça peut être.
Autre petite question qui n'a presque rien à voir, j'aimerais être capable de créer une base de données à partir de mon code, or, pour tout ce qui concerne la communication avec celle-ci, il faut, au préalable, s'être connecté à une base. Comment faire dans ce cas ?
Merci encore et bonne journée !
Hors ligne
Pour snprintf effectivement c'est du C99 non supporté par Visual. En faisant simple on peut avoir #define snprintf _snprintf même si le vrai fix est un peu plus compliqué.
Voir http://stackoverflow.com/questions/2915 … tudio-2010
Pour l'allocation dynamique de tableau, à mon avis la meillleure solution est d'utiliser alloca() qui est dispo à la fois en glibc (gnu) et en Visual C++. Il faut simplement si je me rappelle bien éviter de lever une exception C++ avant la fin de la fonction appelante.
Pour la création de base en mode non connecté, c'est impossible avec postgresql, la solution la plus simple consiste à se connecter à la base template1 (pré-créée automatiquement par initdb) pour exécuter le CREATE DATABASE.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
J'ai bien tenté de la compiler avec MinGW, mais après avoir exécuté le configure, lorsque j'essaye de lancer un "make", il me dit qu'il n'y a rien à faire pour "all" ni pour "all-am".
Par acquis de conscience j'ai essayé et je n'ai pas ce problème:
(pré-requis: configure && make && make install de postgresql avec mingw):
Configuration:
$ cd /c/src/pgstream-1.0
$ ./configure --with-pgsql-includes=/usr/local/pgsql/include --with-pgsql-libs=/usr/local/pgsql/lib/
....la partie finale du résultat...:
checking whether to build static libraries... yes
creating libtool
which: pg_config: unknown command
configure: WARNING: Couldn't find pg_config in PATH.
checking libpq-fe.h usability... yes
checking libpq-fe.h presence... yes
checking for libpq-fe.h... yes
checking for PQexec in -lpq... yes
checking for PQexecParams in -lpq... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/Makefile
config.status: executing depfiles commands
Compilation:
$ make
Making all in src
make[1]: Entering directory `/c/src/pgstream-1.0/src'
source='pgstream.cpp' object='pgstream.lo' libtool=yes \
depfile='.deps/pgstream.Plo' tmpdepfile='.deps/pgstream.TPlo' \
depmode=gcc3 /bin/sh ../depcomp \
/bin/sh ../libtool --mode=compile g++ -DPACKAGE_NAME=\"pgstream\" -DPACK
AGE_TARNAME=\"pgstream\" -DPACKAGE_VERSION=\"1.0\" -DPACKAGE_STRING=\"pgstream\
1.0\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"pgstream\" -DVERSION=\"1.0\" -DSTDC_H
EADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRIN
G_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
-DHAVE_UNISTD_H=1 -DHAVE_LIBPQ_FE_H=1 -I. -I. -I/usr/local/pgsql/include -
g -O2 -c -o pgstream.lo `test -f 'pgstream.cpp' || echo './'`pgstream.cpp
mkdir .libs
g++ -DPACKAGE_NAME=\"pgstream\" -DPACKAGE_TARNAME=\"pgstream\" -DPACKAGE_VERSION
=\"1.0\" "-DPACKAGE_STRING=\"pgstream 1.0\"" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=
\"pgstream\" -DVERSION=\"1.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_
STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=
1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIBPQ_FE_H=1 -I
. -I. -I/usr/local/pgsql/include -g -O2 -c pgstream.cpp -MT pgstream.lo -MD -MP
-MF .deps/pgstream.TPlo -DDLL_EXPORT -DPIC -o .libs/pgstream.lo
g++ -DPACKAGE_NAME=\"pgstream\" -DPACKAGE_TARNAME=\"pgstream\" -DPACKAGE_VERSION
=\"1.0\" "-DPACKAGE_STRING=\"pgstream 1.0\"" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=
\"pgstream\" -DVERSION=\"1.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_
STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=
1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIBPQ_FE_H=1 -I
. -I. -I/usr/local/pgsql/include -g -O2 -c pgstream.cpp -MT pgstream.lo -MD -MP
-MF .deps/pgstream.TPlo -o pgstream.o >/dev/null 2>&1
mv -f .libs/pgstream.lo pgstream.lo
/bin/sh ../libtool --mode=link g++ -g -O2 -o libpgstream.la -rpath /usr/local
/lib -version-info 1:0:0 pgstream.lo -lpq -L/usr/local/pgsql/lib/
libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 shared
libraries
rm -fr .libs/libpgstream.la .libs/libpgstream.* .libs/libpgstream.*
ar cru .libs/libpgstream.a pgstream.o
ranlib .libs/libpgstream.a
creating libpgstream.la
(cd .libs && rm -f libpgstream.la && ln -s ../libpgstream.la libpgstream.la)
make[1]: Leaving directory `/c/src/pgstream-1.0/src'
make[1]: Entering directory `/c/src/pgstream-1.0'
make[1]: Nothing to be done for `all-am'.
make[1]: Leaving directory `/c/src/pgstream-1.0'
Ceci étant, le format .a/.lib pour un simple couple de fichiers (.cpp,.h) n'est pas indispensable.
Dernière modification par dverite (12/04/2012 18:35:14)
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Pour finir, j'ai intégré les modifs pour VS2010 au point où ça compile sans warning ni erreur (et où un test de requête basique fonctionne), j'ai fait le ménage de printemps dans le code, et j'ai mis le résultat sur github:
https://github.com/manitou-mail/pgstream
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Ta bibliothèque fonctionne très bien !
Merci pour tout !
Hors ligne
Pages : 1
