Vous n'êtes pas identifié(e).
Pages : 1
Suis tout à fait d'accord, je recommande très très fortement de spécifier explicitement le schéma de tous les objets.
Cependant, les développeurs étant ce qu'ils sont, je crois qu'une action au niveau de PostgreSQL serait la bienvenue.
Elle pourrait avoir lieu lors de la création d'une fonction "language SQL" par exemple en modifiant le texte fourni par l'utilisateur pour y ajouter le nom du schéma pour tous les objets utilisés par le select, table, vue ou fonction. C'est la même démarche que celle utilisée pour les vues, l'utilisateur n'est pas obligé de préciser un schéma pour spécifier un objet, mais si le schéma n'est pas fourni, il est alors automatiquement ajouté.
Bonjour et merci pour cette réponse qui conforte notre propre analyse.
Cependant, je pense que le problème n'est pas limité à Postgis, même si j'ai utilisé une fonction Postgis comme exemple.
voici un autre exemple :
--connexion postgres (superutilisateur)
CREATE SCHEMA s1;
GRANT USAGE ON SCHEMA s1 TO public;
CREATE FUNCTION s1.ajouteun(IN entree integer) RETURNS integer AS
'select $1 +1'
LANGUAGE sql STABLE;
GRANT EXECUTE ON FUNCTION s1.ajouteun(integer) TO public;
CREATE SCHEMA s2;
GRANT USAGE ON SCHEMA s2 TO public;
set search_path to s2,s1;
CREATE FUNCTION s2.ajoutedeux(IN entree integer) RETURNS integer AS
'select ajouteun($1) +1'
LANGUAGE sql STABLE;
GRANT EXECUTE ON FUNCTION s2.ajoutedeux(integer) TO public;
CREATE ROLE u3 LOGIN;
CREATE SCHEMA u3 AUTHORIZATION u3;
--connexion u3
set search_path to u3,s2,s1;
create table t1 (valeur integer);
create materialized view v1 as select valeur from t1 where ajoutedeux(valeur) > 0 ;et le script issu de pg_dump du schéma u3 (extrait)
....
CREATE SCHEMA u3;
ALTER SCHEMA u3 OWNER TO u3;
SET search_path = u3, pg_catalog;
...
CREATE TABLE t1 (
valeur integer
);
...
CREATE MATERIALIZED VIEW v1 AS
SELECT t1.valeur
FROM t1
WHERE (s2.ajoutedeux(t1.valeur) > 0)
WITH NO DATA;
...provoque une erreur
ERROR: function ajouteun(integer) does not exist
LINE 1: select ajouteun($1) +1
^
HINT: No function matches the given name and argument types. You might need to add explicit type casts.
QUERY: select ajouteun($1) +1
CONTEXT: SQL function "ajoutedeux" during inliningExcellente journée et une fois encore merci pour votre aide
Dominique
merci pour cette réponse.
En premier lieu je voudrais préciser que le problème n'existe que si la vue est matérialisée, pour une vue classique tout va bien.
Voici la réponse au \d+
Materialized view "bss_p.v1"
Column | Type | Modifiers | Storage | Stats target | Description
--------+----------------------+-----------+---------+--------------+-------------
id | bigint | | plain | |
geom | geometry(Point,4326) | | main | |
View definition:
SELECT t1.id,
t1.geom
FROM bss_p.t1
WHERE st_intersects(t1.geom, st_geomfromewkt('SRID=4326;POLYGON((0 40,4 40,4 50,0 50,0 40))'::text));le script extrait du pg_dump à plat est le suivant :
CREATE MATERIALIZED VIEW v1 AS
SELECT t1.id,
t1.geom
FROM t1
WHERE postgis.st_intersects(t1.geom, postgis.st_geomfromewkt('SRID=4326;POLYGON((0 40,4 40,4 50,0 50,0 40))'::text))
WITH NO DATA;avec un REFRESH MATERIALIZED VIEW v1 en fin de fichier
Le problème n'est aussi présent que si la fonction (ici st_intersects) est une fonction "language SQL" et donc définie par une chaîne de caractères.
Merci pour votre attention
Dominique
Désolé, je me rends compte que j'ai été un peu trop succinct.
Je voulais écrire :
d'une vue matérialisée utilisant une fonction exprimée en langage SQL qui utilise elle-même une fonction qui n'est ni dans le schéma en cours ni dans le catalogue.
merci d'avance pour votre aide.
Bonjour,
un collège rencontre un problème lors de la restauration (à partir d'un fichier issu de pg_dump) d'une vue matérialisée exprimée en langage SQL et utilisant une fonction qui n'est ni dans le schéma en cours ni dans le catalogue.
Je vais essayer d'être + clair avec un exemple utilisant la fonction st_intersects de postgis mais le problème est + général
--postgresql 9.4.4
--installation extension postgis 2.1.8 dans schéma postgis
--création d'un utilisateur et d'un schéma du même nom
--le search path par défaut inclut $user et postgis
--connexion utilisateur tout juste créé
CREATE TABLE t1
(
id bigint,
geom geometry(Point,4326)
);
insert into t1 values (1,ST_GeomFromEWKT('SRID=4326;POINT(0 30)'));
insert into t1 values (2,ST_GeomFromEWKT('SRID=4326;POINT(1 43)'));
create materialized view v1 as select t1.id,t1.geom from t1 where st_intersects(t1.geom,ST_GeomFromEWKT('SRID=4326;POLYGON((0 40,4 40,4 50,0 50,0 40))'));
--export (pg_dump) du schéma
--destruction du schéma
--import depuis superutilisateur
--erreur sur la création de la vue matérialisée
ERROR: operator does not exist: postgis.geometry && postgis.geometry
LINE 1: SELECT $1 && $2 AND _ST_Intersects($1,$2)
^
HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts.
QUERY: SELECT $1 && $2 AND _ST_Intersects($1,$2)
CONTEXT: SQL function "st_intersects" during inlining
Nous avons contourné le problème en modifiant manuellement le search path dans le script pour y ajouter le schéma postgis, néanmoins ce n'est qu'un pis aller.
N'ayant pas vu comment résoudre d'une manière plus définitive la difficulté, nous nous tournons vers la communauté en espérant ne pas rabâcher une question mille fois posée.
Merci à tous
Dominique
Merci beaucoup Guillaume pour ces informations/confirmations.
Vous me conseillez de consulter le manuel de référence, c'est toujours par là que je commence, mais par exemple où est-il spécifié que les conditions d'utilisation des triggers dépendent de ceux de la fonction associée ?
Encore merci pour cette réponse.
Excellente journée
Dominique
Bonjour,
je me pose des questions sur les conditions dans lesquelles certains éléments d'une base sont exécutés, en particulier selon les droits du créateur (owner/definer) ou selon les droits de l'appelant (user/invoker)
Par exemple, les conditions dans lesquelles une fonction est effectuée, dépendent de l'option security invoker (défaut) ou definer indiquée à la création de cette fonction.
Sauf erreur, les vues voient leur requête sous-jacente exécutée selon les droits du propriétaire de la vue.
Mais qu'en est-il des triggers ? Quel sont les droits lors de leur exécution ? est-ceux du propriétaire de la table (comme sous Oracle), ceux de l'appelant, ou cela dépend-t-il de la définition de la fonction trigger associée ?
Après pas mal de recherches infructueuses, j'aimerais savoir s'il existe un document et/ou site web résumant tous ces problèmes de droits ?
Merci de vote attention
Dominique
Pages : 1