Vous n'êtes pas identifié(e).
Vous pouvez cependant soit:
* utiliser une fonction, écrite en SQL ou plpgsql ou plperl ou ...
* utilisser des requêtes préparées que vous exécuterez ensuite en passant les valeurs des paramètres présents dans la requêtes sous la forme $1, $2, ...
* utiliser la fonctionnalité de psql si cela vous suffit. Voir psql --help, option -v. Sous cette forme, les variables doivent être de la forme :NOMVAR
Bonjour,
Je pense que dans votre cas d'utilisation, l'utilisation de pl/perl serait 1/ plus simple, 2/ plus performante... si vous en avez la possibilité.
Bonjour,
Quel est votre OS ?
Essayez de savoir dans quel encodage se trouve le fichier de dump et éventuellement de le convertir en UTF-8 s'il ne l'est pas avant de le restaurer.
Sous linux, les commandes file et iconv vous permettront d'effectuer ces tâches.
Salut,
Pour info, vous pouvez vous séparer du "sed 's/ //g'" en utilisant les options -t et -A de psql et ainsi formater sa sortie à votre besoin, sans espaces...
Bonjour,
pgFouine oui, si vous pouvez activer le traçage de toutes les requêtes dans les journaux, mais il ne me semble pas que l'host y apparaisse...
Il reste aussi la solution de filtrer le traffic au niveau réseau avec un tcpdump et/ou tshark...Mais aucun logiciel ne fait pour le moment de rapport d'activité sur ces traces, même si elles seraient effectivement exploitables. Celà implique bien entendu de ne pas avoir de connexion SSL entre le client et le serveur, ce qui est un lourd pré-requis dans certain cas...
oops, j'avais lu trop vite
Bah du coup, est-ce tout ou partie de cette clé primaire qui doit être incrémentée ?
Sinon, une utilisation des séquences est toujours possible ceci dit, en jouant sur la valeur par défaut en fonction de ce qui doit être fait. Mais sans plus de précision, il est dur de répondre en fait...
Bonjour,
sur le serveur, vérifiez que voter serveur écoute bien sur l'interface réseau externe via cette commande :
netstat -taupen|grep 5432Et même si ça peut paraître évident, n'oublier par de redémarrer le service PgSQL.
Le support de Drupal a été amélioré depuis...
À propos du blog.pg.fr, qu'est ce que tu reproche au css ?
En revanche, en passant sur le blog, je me suis apperçus que les articles pointaient sur babar...et qu'il étaient de plus en 404... :S
Mais bon, faut garder à l'esprit que la migration est toujours en cours hein...
J'ai remplacer par 255.255.255.0 et 55.255.255.255 mais ça ne change rien
Perso, j'ai pas trés bien compris ce que tu as fais là.
dans ton pg_hba.conf, pour commencer la première ligne ne représente pas du tout ce que le commentaire explique.
Ensuite, tu devrais remplacer la ligne suivante :
host all all mon ip 0.0.0.0 trustpar :
host all all ton.adresse.ip.ici/32 trustMais comme le disait KrysKool, l'utilisation de trust est plutôt insécure ici...
A propos du port fermé de l'exterieur, j'ai une petite question: sur quelle machine effectue tu le nmap ? Il me *semble* qu'un nmap sur une interface exterieur lancé depuis le serveur lui même ne sera pas filtré par ipfilter (si tu es bien sous linux).
Pour savoir définitivement si ton serveur écoute bien sur *:5432, un netstat lancé sur le serveur sera plus parlant. désolé, je ne suis pas sur ma machine, je ne peux fournir les options précises... Peut-être netstat -taupen | grep 5432 ?