droits pour ALTER TABLE [Résolu]

[say]

Bonjour,
j'ai une fonction qui me lance un calcul tout bête, enfin pas tant que ça mais rien d'extraordinaire.
Cependant, dans ce cas bien précis afin d'améliorer les temps de réponse, je souhaite faire ceci :

Code :

1
2
3
4
 
ALTER TABLE ma_table DISABLE TRIGGER ALL;
UPDATE ma_table à_partir_de mon_calcul;
ALTER TABLE ma_table ENABLE TRIGGER ALL;

ça se passe plutot pas mal...sauf que...ça se passe bien quand c'est moi ("DBA") qui le lance.

mes chers utilisateurs ont le message suivant :

PSQLDatabaseError: PostgreSQL Error Code: (1)
ERREUR: doit ?tre le propri?taire de la relation t_period
CONTEXT: instruction SQL <<ALTER TABLE t_period DISABLE TRIGGER ALL>>

donc petit problème de droit.

est-il possible d'exécuter une instruction avec des privilèges supérieurs à l'instant T . je rêve d'un :

Code :

ALTER TABLE ma_table DISABLE TRIGGER ALL WITH mon_privilège_qui_va_bien

merci d'avance

[grabriel]

Salut,

Tes utilisateurs ont quels droits sur t_period??
Si tu leur attribue des droits seulement sur les triggers??? ou que tu les mettes propriétaire et que tu enlèves les droits que tu veux pas qu'ils aient....??????

[say]

en fait, il semble que pour executer le ALTER, il faille être owner ou superuser...
ce qui n'est donc pas possible pour mes utilisateurs.

la dépersonnalisation est-elle possible sous PGSQL?

j'ai honteusement créer le même topic dans langage SQL, fil de la conversation :
http://www.developpez.net/forums/sho...37#post1829837

[grabriel]

En faite je pensais à ce que TU leur attribue les droits sur les triggers, sous pgadminIII (c'est le plus simple y'a juste a cliquer) avec Postgres 8.x tu peux spécifier que certains droits à des personnes et donc donner à tes utilisateurs le droit de modifier la table mais pas supprimer, d'utiliser les triggers mais de ne pas insérer etc...

[say]

j'ai bien compris....sauf que les droits pour faire un ALTER ne sont pas dans cette fameuse liste sous pgAdmin.

[grabriel]

Arghhhhh!!!

Autant pour moi!!!!! désolé faudrai que je change de lunettes!

[dieu_du_net]

utilise plutot GRANT ALTER TABLE TO ton_utilisateur ON t_period : cela permet d'autoriser l'utilisteur ton_utilisateur à faire des modifs sur la table t_period qui a comme owner si j'ai bien saisi le DBA (toi). sinon je ne vois pas comment tu pourrais acceder à une table qui n'ai pas à toi.

bonne continuation

[say]

euh...elle vient d'où cette syntaxe??
sous PGSQL, il a pas l'air d'en vouloir...

[dieu_du_net]

cette commande marche pour moi postgres 8.2

Code :

GRANT SELECT, UPDATE, INSERT ON TABLE t_period TO ton_user

excuses moi pour la syntaxe.

bonne continuation

[say]

je suis en 8.1 mais c'est pas le problème.
Moi aussi

Code :

GRANT SELECT, UPDATE, INSERT ON TABLE t_period TO ton_user

fonctionne sauf qu'on parlait d'un

Code :

GRANT ALTER TABLE t_period TO ton_user

ce qui n'est pas la même chose et n'est pas inclus dans la séquence précédente...
une autre idée?

[dieu_du_net]

Et en faisant

Code :

GRANT ALL ON perid_t TO user;

est ce que tes commandes fonctionnent pour ton utilisateur user ??

[say]

non plus !!!

Bon, cette fois, c'est sur...ce n'est pas possible..il faut être superuser.
on a fait un paquet de tentative...on a bossé sur l'IRC de postgresql...

et finalement, on a choisi une autre solution..

merci à tous..

A+