Discussion :

[looping]

Bonjour,

j'aurais une question concernant le répertoire d'installation des fonctions.

Lors de l'installation de l'extension crypto, je me suis aperçu que les fonctions de cette extension
se sont installées dans le répertoire function du schema public.

Du coup, elles sont mélangés avec mes propres fonctions, ce qui n'est plus très lisible.

Est ce qu'il y une bonne pratique en la matière ou on a pas le choix ?

Par exemple, est ce une bonne idée de créer un schéma vide ou on s'installe toutes les extension ?


Cordialement

[Michel.Priori]

Bonjour,

Le plus propre étant de ne pas utiliser le schéma "public" pour vos objets.
MAIS c'est contraignant !
Pourquoi ? pour des raisons de sécurité !

Et c'est justement quand on maîtrise les questions de sécurité qu'on commence à en faire ^^

Lire avec attention cette page https://docs.postgresql.fr/14/ddl-schemas.html

[looping]

Bonjour,

j'ai crée un autre schéma, ensuite je l'ai mis en chemin prioritaire avec search_path

Et là, si j'installe pgcrypto, ses fonctions interne s'installent dans ce nouveau schema

Cela pourrait être une solution à mon problème.
Mais est ce une bonne pratique ?

Cordialement

[Michel.Priori]

Mais est ce une bonne pratique ?

De quoi est constituée "une bonne pratique" ?

De manière consensuelle = ce que tout le monde fait = la loi du nombre
De manière réfléchie = celle qui amène le moins de désagréments par la suite = éviter les emm..des

Quel est le problème soulevé ici :

Du coup, elles sont mélangés avec mes propres fonctions, ce qui n'est plus très lisible.

Au delà de la "lisibilité" il y a le problème du doublon de nom de procédure vs la "disponibilité" du code.
En plaçant le code dans le schéma public, la procédure s'invoque facilement car "public" est par défaut dans le path.

La notion de schéma est, en premier lieu, un espace de nom (et éventuellement une commodité de sécurité).
Un espace de nom permet de créer plusieurs objets "au même nom" via des "chemins" différents.
Ainsi ma_proc n'est pas la référence du même objet en fonction du schéma ; par exemple public.ma_proc, code.ma_proc, dbo.ma_proc, scott.ma_proc sont des objets complètement dissociés.

LA bonne façon d'invoquer le bon objet est de le nommer complètement ; <schéma>.<nom>
Mais, c'est chiant...

Alors on a voulu simplifier l'écriture en imaginant un "chemin" par défaut.
Sous Pg ce chemin est "public".
Sous Pg toujours, on peut modifier le chemin soit globalement, soit pour la session.

Mais en jouant trop du chemin par défaut, on risque de créer des confusions ; exemple : "j'ai supprimé la table T, mais elle existe quand même, la preuve je peux faire SELECT * FROM T, et, le plus drôle c'est que je peux en recréer une !"

Donc pour moi :

1. Ne pas modifier le path par défaut
2. créer des schémas - n'utiliser le schéma public que pour les bases sans importance ; les autres méritent mieux !
3. utiliser la syntaxe <schéma>.<nom> tout le temps (cela implique d'avoir réfléchi aux noms des schémas !)
4. Créer des rôles - et bien comprendre ce qui se passe derrière GRANT SELECT ON ALL TABLES IN SCHEMA ... TO ...;

Ce qui rejoint la doc :

Pour chaque méthode, pour installer des applications partagées (tables utilisées par tout le monde, fonctions supplémentaires fournies par des tiers, etc.), placez-les dans des schémas séparés. N'oubliez pas d'accorder les droits appropriés pour permettre aux autres utilisateurs d'y accéder. Les utilisateurs peuvent ensuite faire référence à ces objets supplémentaires en les qualifiant avec le nom du schéma, ou bien ils peuvent placer les schémas supplémentaires dans leur chemin de recherche, suivant leur préférence.