Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
A l'attention de chaugab. Est-ce que vous avez réussi à importer le fichier json tel quel ?
ou bien avez-vous du retirer les retours à la ligne ?
Merci !
Je le fais :
- type par type : tables , functions, sequences
- schema par schema
- groupe par groupe
... assez fastidieux
Le pb c'est qu'on est obligé de connaitre les groupes qui ont servi à donner les droits
syntaxe :
REVOKE ALL ON ALL TABLES IN SCHEMA public FROM GROUP "nom_du_groupe";
REVOKE ALL ON ALL FUNCTIONS IN SCHEMA public FROM GROUP "nom_du_groupe";
REVOKE ALL ON ALL SEQUENCES IN SCHEMA public FROM GROUP "nom_du_groupe";
Bonjour,
J'ai des tables sur lesquelles des groupes ont des droits.
Sur toutes ces tables (et séquences associées) je souhaite enlever tous les droits de ces groupes.
( après cette manip je donnerai les droits à un nouveau groupe )
J'ai cru comprendre qu'on était déjà obligé de le faire schema par schema ?
et dois-je le faire groupe par groupe ?
Quelle est la syntaxe ?
Merci d'avance
C'est coûteux et dangereux mais il n'y a pas d'autres solutions à ma connaissance.
Attention notamment aux noms de table entre guillemets. exemple data."analyse" , ce sed ne fonctionne pas
ça a l'air de fonctionner :
sed 's/schema1.matable/schema2.matable/g'
(ne pas oublier le /g si l'occurence apparait plusieurs fois sur une même ligne)
Je remplacerais bien schema1.matable par schema2.matable mais je ne sais pas si cela suffit.
En fait le schema apparaît à d'autres endroits dans le dump. Pas simple
Bonjour ,
Voici ce que je dois faire et qui ne fonctionne plus : dump d'une table puis restauration dans une autre BD en changeant le schema
Avant je fais le dump : pg_dump --host monserveur --port monport --username postgres --format plain --no-owner --no-privileges --verbose --table schema1.matable
puis pipe sed 's/search_path = schema1/search_path = schema2/'
Mais le dump a changé au nouveau du search path (SELECT pg_catalog.set_config('search_path', '', false)
et le cherche remplace ne fonctionne plus
D'où une première question : y a-t-il moyen de revenir à un dump avec search path et où la table est indiquée sans son schéma ?
Et sinon il y a peut-être plus simple dorénavant par rapport au besoin initial
Bonjour,
Dorénavant le dump contient l'instruction :
SELECT pg_catalog.set_config('search_path', '', false);
Savez-vous ce que cela signifie ?
Merci !
Bonjour,
Je viens d'installer PgaAdmin 4 3.1
et je cherche comment afficher l'état du serveur et notamment le fichier journal.
Merci d'avance
Bonjour ,
La fonction round complète systématiquement avec des 0 quand le nombre initial a moins de décimales.
Peut-on éviter cela ?
exemple :
round( 5.1 , 2 ) donne 5.10
et je voudrais 5.1
Merci d'avance
J'avais écrit que pg_column_size(monchamp) <= pg_column_size(monchamp::numeric(3,1)).
Mais ...
Si je crée une nouvelle table avec un champ numeric(3,1) et que je copie le champ numeric de la première table dans la deuxième , en le castant en numeric(3,1) , alors pg_column_size du champ numeric(3,1) a la même valeur que pg_column_size du champ numeric.
Donc si on prend la fonction pg_column_size comme référence , on peut dire que numeric et numeric(3,1) occupent la même taille disque.
PS :
pour les 2 tables j'ai ensuite fait un vaccum + analyse + full et j'ai les mêmes résultats pour la fonction pg_column_size
Bonjour,
Je suis en 9.1 côté serveur. et je cherche à comparer les 2 types numeric et numeric(p,s)
Ce que j'ai déjà pu remarquer :
inconvénient du numeric(p,s) :
Si je mets une colonne en type numeric(3,1) par exemple, alors le système affiche systématiquement le chiffre après la virgule :
si je saisis 5 il va afficher 5.0 , ce qui pour moi n'est pas très beau, mais aussi ne veut pas dire la même chose
(on aurait mesuré avec une précision de 1)
autre inconvénient du numeric(p,s) :
j'ai une table matable avec un champ monchamp en numeric , dont les valeurs vont de -99.9 à 99.9 avec au max 1 chiffre après la virgule.
Pour ce champ je voudrais trouver un mode de stockage plus économique en place disque.
Et bien en faisant :
SELECT DISTINCT pg_column_size(monchamp) , pg_column_size(monchamp::numeric(3,1)) FROM matable ;
la 2ème colonne de la requête est toujours plus élevée que la 1ère.
Du coup je ne vois pas comment gagner de la place de stockage pour mon champ
J'ai trouvé.
La console PSQL ne fonctionne pas avec la version 1.14 si on se connecte sur un serveur 8.1.
J'ai installé la version 1.12.3 de Pgadmin et cela fonctionne.
Bonjour ,
lorsque je lance PSQL console , cela me sort immédiatement avec le message (subliminal) "la conversion entre WIN1252 et LATIN9 n'est pas supportée"
Avez-vous une idée ?
Pages : 1
