Discussion :

[alassanediakite]

Salut
Je constate un problème avec CURRENT_USER lors d'une suppression en cascade.
La situation...(9.4.1)
1-->_______
Je me connecte avec le compte postgres
Création de deux tables liées avec suppression en cascade...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
CREATE TABLE ta
(
  ida integer NOT NULL,
  v character varying,
  CONSTRAINT ta_pkey PRIMARY KEY (ida)
)
 
CREATE TABLE tb
(
  idb integer NOT NULL,
  ida integer,
  v character varying,
  CONSTRAINT tb_pkey PRIMARY KEY (idb),
  CONSTRAINT tb_ida_fkey FOREIGN KEY (ida)
      REFERENCES ta (ida) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE CASCADE
)

La table qui enregistre l'historique de CURRENT_USER

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
CREATE TABLE th
(
  v character varying,
  idh serial NOT NULL,
  CONSTRAINT th_pkey PRIMARY KEY (idh)
)

Les triggers

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
CREATE OR REPLACE FUNCTION huser() RETURNS trigger AS
$$
begin
	insert into th(v) values(current_user);
	return old;
end
$$
  LANGUAGE plpgsql
 
 CREATE TRIGGER huser
 BEFORE DELETE
 ON ta
 FOR EACH ROW
 EXECUTE PROCEDURE huser();
 
 CREATE TRIGGER huser
 BEFORE DELETE
 ON tb
 FOR EACH ROW
 EXECUTE PROCEDURE huser();

Les données

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
INSERT INTO ta(ida, v) VALUES (1, 'A'), (2, 'B');
INSERT INTO tb(idb, ida, v) VALUES (1, 1, 'Aa'), (2, 1, 'Ab'), (3,2, 'Ba'), (4, 2, 'Bb');

2-->___________
Je me connecte avec un autre compte

La suppression dans ta (sera fait avec le nouveau compte) qui provoquera une suppression en cascade (avec le compte postgres!)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
delete from ta where ida=1;

Le contenu de l'historique de CURRENT_USER

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
select * from th;

Alors, la question: est ce un comportement normal?
Je voulais mettre ne place un mécanisme de contrôle de modification et de suppression (vous ne supprimer ou modifier que si vous êtes propriétaire ou administrateur). Mais ce comportement de PostgreSQL est un frein.
@+

[alassanediakite]

Salut
La réponse est donnée par un expert.

Oui, c'est un comportement normal. La vérification et la suppression des données référencées sont effectuées par l'utilisateur propriétaire de la table.

Ce comportement est-il pertinent avec la gestion des privilèges?
Qu'en est-il d'autres SGBD?
@+

[SQLpro]

Non, c'est anormal ! Mais beaucoup d'éditeurs ont confondus les notions d'utilisateurs, de propriétaire voir de schéma SQL (c'est notamment toujours le cas chez Oracle).

A +