Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
Pages : 1
#1 Re : Général » Suppression de droits » 10/01/2019 17:44:04
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";
#2 Général » Suppression de droits » 10/01/2019 16:47:01
- jeanphi45
- Réponses : 3
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
#3 Re : Général » [PostgreSQL 9.6.9] dump d'une table » 10/07/2018 14:14:09
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
#4 Re : Général » [PostgreSQL 9.6.9] dump d'une table » 10/07/2018 11:58:16
ç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)
#5 Re : Général » [PostgreSQL 9.6.9] dump d'une table » 10/07/2018 11:34:54
Je remplacerais bien schema1.matable par schema2.matable mais je ne sais pas si cela suffit.
#6 Re : Général » [PostgreSQL 9.6.9] dump d'une table » 10/07/2018 11:33:00
En fait le schema apparaît à d'autres endroits dans le dump. Pas simple
#7 Général » [PostgreSQL 9.6.9] dump d'une table » 10/07/2018 11:03:59
- jeanphi45
- Réponses : 13
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
#8 Re : Général » [PostgreSQL 9.6.9] pg_dump » 10/07/2018 10:52:09
#9 Général » [PostgreSQL 9.6.9] pg_dump » 10/07/2018 10:27:34
- jeanphi45
- Réponses : 3
Bonjour,
Dorénavant le dump contient l'instruction :
SELECT pg_catalog.set_config('search_path', '', false);
Savez-vous ce que cela signifie ?
Merci !
#10 pgAdmin4 » Etat du serveur » 02/07/2018 14:27:34
- jeanphi45
- Réponses : 0
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
#11 Re : Général » Arrondi » 21/10/2015 13:55:14
#12 Général » Arrondi » 21/10/2015 10:59:36
- jeanphi45
- Réponses : 2
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
#13 Re : Général » Sujet de débat : comparatif entre numeric et numeric(p,s) » 02/07/2014 10:38:07
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
#14 Général » Sujet de débat : comparatif entre numeric et numeric(p,s) » 01/07/2014 11:02:29
- jeanphi45
- Réponses : 1
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
#15 Re : PSQL » [pgadmin 1.14] erreur PSQL » 21/02/2012 17:08:23
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.
#16 PSQL » [pgadmin 1.14] erreur PSQL » 21/02/2012 12:04:01
- jeanphi45
- Réponses : 1
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