Vous n'êtes pas identifié(e).
Pages : 1
Merci rjuju pour la suggestion de création de fonction. Ce n'est pas encore une partie de Postgres que je maîtrise. Je vais donc me renseigner d'abord.
Effectivement votre remarque gleu est plutôt juste. C'est simplement que je me projetais sur la suppression par inadvertance par un utilisateur. J'imagine qu'il est le plus souvent préférable de travailler avec une table dont une colonne a été supprimée par accident plutôt que pas de table du tout.
Si je trouve une solution satisfaisante je la posterai.
Bonne journée.
"Le droit de modifier ou de détruire un objet est le privilège du seul propriétaire."
ça a le mérite d'être clair en effet.
Dans l'idée que je me faisais des privilèges utilisateurs de Postgresql, la modification/création/suppression des colonnes d'une table pouvait se faire autrement que part le propriétaire. C'est un peu dommage parceque mon souhait final est de permettre à mes utilisateurs de créer/supprimer/modifier les colonnes d'une table sans qu'ils puissent pour autant supprimer cette dernière. Or en les plaçant propriétaires, la suppression de la table leur est rendue possible.
Merci ruizsebastien pour ces infos.
Bonjour tout le monde,
Je commence en précisant la version de mon PostgreSQL (bien qu'avec la 11 j'ai le même problème) : PostgreSQL 9.5.9, compiled by Visual C++ build 1800, 64-bit
Je remarque qu'il n'est pas possible pour mes utilisateurs de créer ou de supprimer une/plusieurs colonnes de la table, sachant que leurs privilèges sont les suivants:
-1 des privilèges UC au niveau du schéma.
-2 Des privilèges arwdDxt sur la table de ce schéma
Pour qu'ils puissent ajouter/supprimer des colonnes il semblerait qu'ils doivent être propriétaire de la table. C'est en tout cas ce que semble m'indiquer le réponse à la requête:
ERROR: ERREUR: doit être le propriétaire de la table test
SQL state: 42501
Aurai-je raté quelque chose dans l'attribution de mes privilèges, ou bien l'attribbution de la propriété est-elle nécessaire?
Par avance, je vous remercie.
Cordialement,
Rémi
Bonsoir,
Je n'ai plus accès à l'instance Postgresql sur laquelle j'ai observé les problèmes rencontrés. C'est encore frais dans ma mémoire et je me souviens qu'il n'y avait pas de message d'erreur. Simplement ce constat que les fichiers shapefiles chargés depuis le loader dans la base ne reprenaient pas les droits utilisateurs (DEFAULT PRIVILEGES) qui sont définis dans le schéma. C'est un comportement que j'ai seulement remarqué avec Postgres 9.6 et postgis 2.0 . Avec des versions supérieures je n'ai pas retrouvé ce comportement et les shapefiles, devenus tables, reprenaient bien les droits utilisateurs du schéma dans leur propriétés.
Cordialement
Le loader doit s'ajouter à Postgres avec l'extension PostGIS.
Jusqu'à présent j'ai toujours constaté que Postgres reporté les droits utilisateurs (SELECT, DELETE, UPDATE, etc.) défini au niveau du schéma dans les tables. Je viens de procéder à un autre test (tout simple que j'avais zappé), j'ai crée une table dans le schema_etude ayant les droits utilisateurs suivant:
ALTER DEFAULT PRIVILEGES IN SCHEMA schema_etude
GRANT SELECT ON TABLES
TO grp_1;
ALTER DEFAULT PRIVILEGES IN SCHEMA schema_etude
GRANT SELECT ON TABLES
TO grp_2;
Suite à la création de la table, je constate qu'elle reprend bien les droits utilisateurs du schéma ci-dessus.
Maintenant comme je le disais avec shape and dbf loader, ainsi que l'invite de commande, je n'ai pas ce report des droits qui se fait dans la table. Je tends à croire que c'est un problème de version du loader qui pose problème, PostgreSQL 9.6 s'exécutant avec Postgis 2.0 et non 3.0 comme le font PostgreSQL 11 et 12.
Bonjour tout le monde,
J'ai recours au chargement de données shapes via le shapefile and DBF loader. Sur des versions Postgres 11 et 12 les shapefiles chargés en tables récupèrent bien les droits des utilisateurs précisés dans le schéma. En revanche avec une version PostgreSQL 9.6 et toujours en chargeant avec le loader je n'ai plus cette transmission des droits dans les tables.
Je cherche donc la réponse au problème. Je n'ai pas l'impression que ce soit le loader puisqu'en important une table en plain text avec l'invite de commande j'ai le même problème. Je ne vois que la version ou alors un paramètre que j'ignore.
Auriez-vous une idée svp?
Merci, Rémi
Bonjour dverite,
Merci pour les explications, c'est clair et net, j'ai pu vérifier de mon côté.
Bonne journée.
Hello tout le monde,
J’aurai une question au sujet du renommage du champs gid.
Je souhaiterai renommer gid en id.
Pour se faire j’ai tout d’abord procéder à ce renommage en allant dans les propriétés de la table et en modifiant la colonne gid. Déjà à cette étape je remarque une chose curieuse, c’est que le type de données du gid est de l’integer. Alors que dans le sql de la table il est bien spécifié que c’est du serial. Il s’avère qu’en modifiant le nom et seulement le nom gid pour id et en acceptant les modifications, j’ai mon type de donnée qui passe de serial à integer.
En soit malgré ce changement, le comportement de la colonne est normal et elle réagit toujours en conséquence de ce qui est renseigné dans sa séquence.
Ma première question est donc : Est-ce qu’il y a un risque à garder une telle configuration pour un champ aussi important qui constitue en plus ma clé primaire ?
Comme solution alternative, j’ai pensé à créer une nouvelle colonne id, avec serial en type de données. Dans la foulé est créé sa séquence par postgres. N’ayant plus d’utilité pour gid je le supprime et désigne ma colonne id comme nouvelle clé primaire de la table.
Mais j’ignore si ce genre de manips peut occasionner des dommages dans la table… Auriez-vous d’autres suggestions ou remarques ?
Je vous remercie.
Rémi
Merci Gleu pour ces infos. Je n'avais pas du tout saisi cette différence entre attributs et droits.
Bonne journée,
Rémi
Que je comprenne bien. Les droits correspondent à : SELECT, INSERT, UPDATE, DELETE, RULE, REFERENCES, TRIGGER, CREATE, TEMPORARY, EXECUTE et USAGE (https://docs.postgresql.fr/8.1/privileges.html).
C'est de ça qu'un utilisateur hérite de son groupe utilisateur.
Parcontre si le groupe utilisateur peut créer des rôles, grâce à son attribut, et que l'utilisateur ne le peut pas, parcequ'il ne possède pas l'attribut (pour reprendre mon exemple). Alors malgré l'appartenance de l'utilisateur au groupe, il ne pourra toujours pas créer de nouveaux utilisateurs. Ai-je bien saisi? De toute façon je vais faire un test.
Bonjour,
Désolé pour ce titre pas très explicite, je pense être plus clair dans mes explications. Je rencontre le problème que je vous détaille ci-dessous :
J’ai décidé de créer mes utilisateurs à partir d’un fichier plain text (écrit en SQL). Mes utilisateurs ouvrent le fichier plain text, y spécifie leur nom de user qui s’écrit prénom.nom et leur mot de passe. Après cette étape, j’ouvre mon invite de commande et y tape le code suivant :
C:\Program Files\PostgreSQL\9.6\bin>createuser -U rmayou -h SRV-GREGIB -p 5432 prénom.nom < "C:\Users\rmayou\Desktop\postgresl_administration\CHARGEMENT_UTILISATEURS\recup_user.sql"
Le fichier plain text spécifié contient le code suivant :
--
-- PostgreSQL database cluster dump
--
SET default_transaction_read_only = off;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = on;
--
-- Roles
--
CREATE ROLE "prenom.nom";
ALTER ROLE "prenom.nom" WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB LOGIN NOREPLICATION NOBYPASSRLS PASSWORD ‘mot_de_passe';
--
-- PostgreSQL database cluster dump complete
--
Dans l’invite de commande j’ai un retour positif avec création de l’utilisateur lorsque je m’octroie les droits de superuser. J’ai un retour négatif lorsque je ne m’octroie pas ce droit :
…..CHARGEMENT_UTILISATEURS\recup_user.sql"
Mot de passe :
createuser : la création du nouvel rôle a échoué : ERROR: permission denied to create role
Chose très bizarre est que dans un cas comme dans l’autre, mon rôle d’utilisateur est rattaché un rôle de groupe utilisateur qui lui a le droit de superuser. En connaissance de cet élément je devrais dans les deux cas pouvoir créer les utilisateurs, sachant que mon rôle a le droit INHERIT.
Auriez-vous déjà rencontré un problème de ce genre ?
Merci d’avance, Rémi
Merci à tous les deux. Je vais prendre davantage de renseignements durant le mois. Si jamais je viens à buter sur des éléments je relancerai ce topic.
Bonne journée.
D'accord, je comprends. Je vais effectuer cette opération et constater les éventuels changements.
Quand vous me demandiez la raison du problème, la manque d'espace disque. Vous pensiez à un autre paramètre important que celui du Vacuum ?
Merci pour ce premier retour.
Le problème que je rencontre est effectivement celui du manque d'espace disque. J'essaie avec la documentation de comprendre les requis à une bonne installation PostgreSQL et de savoir comment mon instance a été installée vis-à-vis de ces conseils. A cet effet j'ai exécuté la commande pg_settings, qui me semble être une première piste.
Pour reprendre votre explication ci-dessus. Si j'ai bien compris, vous voulez dire qu'on peut s'attendre à ce que la représentation de Postgre soit plus efficace que d'autres, notamment pour des données à valeurs importantes?
En examinant d'autres tables, je remarque effectivement des différences de poids entre intérieure et extérieure. La mauvaise surprise est que ces différences sont rarement en faveur de Postgre.
Bonjour tout le monde,
J'ai effectué et continue d'effectuer des recherches dans les répertoires Installation et Optimisation de ce forum, voire même ailleurs. Cependant je n'ai pas trouvé réponse à ma question qui est la suivante:
Est-il possible de réduire le poids des tables dans PostgreSQL ?
Avant de me lancer dans le SGBD, j'avais lu un retour d'utilisateur indiquant que des données stockées dans une base de données PostgreSQL voyaient leur poids réduit.
Aujourd'hui je travaille avec un base PostgreSQL dont je découvre l'installation, faîte antérieurement à mon arrivée. Je constate que le poids des tables n'est pas moindre que lorsqu'elle se trouve sauvegardée en shape file (il s'agit de données géographiques). Le poids est même supérieur dans PostgreSQL du fait de l'index et de la table TOAST qui s'ajoutent.
Auriez-vous une solution, des points sur lesquels m'éclairer? De mes lectures j'ai relevé deux éléments importants, l'un est le tablespace. Une base avec des tablespaces bien organisés exécute les traitements avec beaucoup plus d'efficacité. Un paramètre important donc, mais il n'est pas fait allusion au poids de la donnée. Le second point est le partitionnement des tables, qui lui aussi semble améliorer les traitements.
Rémi
Pages : 1
