Vous n'êtes pas identifié(e).
Pages : 1
Effectivement : un WHERE en plus pour ne travailler que sur un seul schéma et ça correspond tout à fait à mon besoin.
En fait, quand ça ne marchait pas, je ne savais pas vraiment ce que je devais attendre de ma requête ...
et donc, au vu de l'autre lien, je pensais qu'il fallait les droits postgres.
Ce n'est que quand j'ai pu voir le résultat partiel du select, que j'ai compris qu'on ne modifiait pas "en force" le contenu des tables systèmes mais que l'on voulait générer les grant ...
Une fois ça compris, il était simple de voir que le nom du shéma manquait
Quand on manque de bases (sans mauvais jeu de mot), tout devient plus compliqué
merci encore
DB
Bon, ben j'ai finalement trouvé !
J'en suis surpris moi même ...
en fait, les deux exemples identiques trouvés sur le net, travaillent sur des tables dans le schema "public" sous entendu par défaut.
Comme ici je travaille dans un autre schéma, il faut le spécifier en plus
select 'grant select on meta.' || tablename || ' to nwazen;' from pg_tables where schemaname = 'meta'
la liste des commandes générées sort dans la fenetre --> un copier coller et ça roule
Merci à rjuju de son intervention
DB
pour info, le select marche bien :
select 'grant select on ' || tablename || ' to nwazen;' from pg_tables where schemaname = 'meta'
renvoie
?column?
grant select on traits_animaux to nwazen;
grant select on etudes to nwazen;
grant select on raunkiaer_lifeform to nwazen;
...
donc, c'est plutot l'exécution ensuite qui coince
Des droits manquants sans doute
Oui : excusez moi, j'avais aussi effectivement un message d'erreur dans cette version
Avec celles ci :
/usr/local/pgsql/bin/psql -h /var/run/postgresql -qAt -c "select 'grant select on ' || tablename || ' to nwazen;' from pg_tables where schemaname = 'meta'" URUEFM_divers
/usr/local/pgsql/bin/psql -h /var/run/postgresql -qAt -c "select 'grant select on ' || tablename || ' to nwazen;' from pg_tables where schemaname = 'meta'" URUEFM_divers |/usr/local/pgsql/bin/psql -h /var/run/postgresql URUEFM_divers
J'arrive à la demande du mot de passe sans injure particulière
J'ai fait un copier coller exact ne voyant pas de risque à le faire
et merci pour la réponse
Ne saisissant pas l'interet de la fin de la requête, j'ai tenté les deux versions pour voir l'effet ...
Bonjour,
j'ai trouvé deux réponses à cette question mais ça ne semble pas fonctionner.
soit je lance cette requête dans la fenêtre SQL d'un phppgadmin (en tant que simple user car sur ce lien : http://www.postgresqlfr.org/support:tru … _un_schema on ne me dit pas de faire autrement (enfin un simple user qui a tous les droits qd meme))
SELECT 'GRANT SELECT ON '||table_schema||'.'||table_name||' TO userpg;' FROM information_schema.TABLES WHERE table_type='BASE TABLE' AND table_schema='nom_schema';
ça ne me jette pas mais ça ne fait rien
Soit je lance celle-ci
/usr/local/pgsql/bin/psql -h /var/run/postgresql -qAt -c "select 'grant select on ' || tablename || ' to userpg;' from pg_tables where schemaname = 'nom_schema'" nombase |psql nombase
trouvée là :
http://trac.evolix.net/infogerance/wiki/HowtoPostgreSQL
et là, ça me demande le mot de passe de postgres que bien sûr je n'ai pas à connaitre.
Cette ligne de commande est lancée dans un terminal où je suis entré en root puis passé en su postgres.
Qqun a t'il une idée de ce que je rate ?
ou une autre solution ...
Peut-être que ce que je prends pour des noms de tables système est en fait des noms à changer ...
merci d'avance
DB
j'ai remplacé mes vrais par userpg, nom_schema, nombase uniquement pour ces 3 valeurs. J'ai réellement tapé le reste tel que ...
Hé bien merci pour tout: je vais tenter de rendre tout ça plus "propre" avec cette aide ...
À la prochaine
Didier
OK merci
ça nous semblait souple ... et ça l'est le plus souvent quand il n'y a pas de pb.
Simplement on ne maîtrise rien en fait.
Mais est-ce envisageable de "recoder" des bases existantes ou est-ce que c'est trop tard (je n'ai pas trop envie de casser des choses qui, sauf accident, ne tournent pas trop mal ?
Et nous dire ce que valent server_encoding et client_encoding dans votre session ?
et pour ça : je ne sais pas vraiment comment récupèrer ces infos facilement ...
J'ai regardé la doc et pourrais peut-être en inscluant la requête dans la page PHP mais simplement, je ne vois pas ...
Bon, on a trouvé une correction manuelle et on sait pourquoi :
Suite à une erreur, j'ai effacé la base, pris le dump en ascii et refait la base.
Lors de cette manip l'encodage a changé les 'é' et autres 'è' en diverses cochoneries dans les requêtes des vues alors que ça restait de braves 'e' accentués dans la base donc les selects ne trouvaient rien de correspondant.
Nous avons corrigé les requêtes à la main en fixant l'encodage du navigateur où nous faisons tourner PhpPgAdmin (ISO-8859-15) et tout est rentré dans l'ordre.
Mais n'y aurait-il pas moyen de graver les encodages dans le marbre afin d'éviter que ça se reproduise à chaque restauration de base (même sans faire des erreurs tous les jours, on n'est pas à l'abri ....)
De toutes façons : merci de vos réponses rapides 
pas d'erreur : un simple select sur 'congés' renvoyait les lignes concernées et maintenant dit "pas de résultat" via PhpPgAdmin et les bonnes lignes via la ligne de commande de psql
A priori, on n'a touché à rien mais sur un serveur c'est dur d'être sûr ...
Bonjour,
comme dit dans le titre : jusqu'à vendredi, ça marchait bien et depuis, si l'affichage (via phppgadmin par exemple) est toujours correct, les requêtes ne fonctionnent plus !
Si qqun a une idée sur pourquoi ça a pu se mettre à dysfonctionner d'un seul coup et comment revenir à l'état antérieur, je suis preneur.
merci d'avance
en fait, en ligne, ça marche.
Ce n'est que via PhpPgAdmin que les accents ne sont plus reconnus.
L'encodage à dû sauter : pourquoi, le mystère reste entier.
Donc, la question devient : peut-on facilement gérer l'encodage en ligne de commande d'une base postgres (celle-ci est en ASCII-SQL)
Pages : 1
