Est-il recommandé d'installer des extensions dans le schéma pg_catalog?
Puisque les objets dans pg_catalog le schéma est implicitement dans le search_path ( docs ), serait-il recommandé d'installer des extensions dans ce schéma?
N'installez pas d'extensions dans pg_catalog (Sauf si c'est leur valeur par défaut: très peu d'extensions sont conçues de cette façon), car vous ne jouez pas avec le catalogue système, jamais. @ Chris montre une des raisons pour lesquelles. Il y en a d'autres.
Cependant, le schéma "public" n'est en rien spécial . C'est juste le schéma par défaut qui est pré-installé dans les distributions standard afin que nous puissions commencer immédiatement. Certains administrateurs DB n'utilisent pas du tout le schéma "public", certains le suppriment même.
CREATE EXTENSION n'est pas affilié au schéma "public". Il s'installe dans le schéma actuel sauf indication contraire - sauf que certaines extensions ont un schéma prédéfini (comme PGQ/Londiste ). La documentation:
nom_schéma
Nom du schéma dans lequel installer les objets de l'extension, étant donné que l'extension permet de déplacer son contenu. Le schéma nommé doit déjà exister. S'il n'est pas spécifié et que le fichier de contrôle de l'extension ne spécifie pas non plus de schéma, le schéma de création d'objet par défaut actuel est utilisé .
N'oubliez pas que l'extension elle-même n'est pas considérée comme faisant partie d'un schéma: les extensions ont des noms non qualifiés qui doivent être uniques à l'échelle de la base de données. Mais les objets appartenant à l'extension peuvent être dans des schémas.
Accentuation mienne.
Décidez comment gérer les utilisateurs, les schémas et le search_path:
Alors décide où installer les extensions. Vous pouvez installer sur n'importe quel schéma de votre choix et inclure ce schéma dans le search_path Par défaut pour tous les utilisateurs ou seulement pour certains ou aucun utilisateur (de sorte que des références qualifiées soient requises). Tout dépend de ce que vous voulez réaliser.
Quoi que vous fassiez, restez cohérent.
J'aime installer des extensions (qui le permettent) dans un schéma "d'extensions" dédié, que j'inclus dans le défaut search_path après "public" (et "$ user" - si vous l'utilisez). Aide à une séparation nette de mes propres fonctions publiques et d'autres objets publics. Mon réglage dans postgresql.conf:
search_path = "$user",public,extensions
Ou:
search_path = public,extensions
Et j'installe des extensions avec:
CREATE EXTENSION some_extension SCHEMA extensions;
Une chose à noter: De cette façon, vous pouvez "masquer" des objets (non qualifiés) dans le schéma extensions derrière des objets du même nom (et paramètres) dans le schéma public.
En relation:
Installation d'extensions dans pg_catalog ne sont pas, à ma connaissance, déconseillés. Vous devez utiliser le schéma public par défaut, qui se trouve également dans le search_path par défaut.
Pourquoi?
À titre d'exemple, je travaillerai avec l'extension pageinspect que j'ai déjà créée dans le schéma public. Toutes les fonctions sont, par défaut, accessibles à tous les schémas de la base de données si elles se trouvent dans le schéma public.
Maintenant, j'essaye de le déplacer vers le pg_catalog schéma, utilisation
ALTER EXTENSION pageinspect SET SCHEMA pg_catalog;
et cela fonctionne très bien.
Mais...
Essayez de le déplacer à nouveau, retournez au schéma public en utilisant
ALTER EXTENSION pageinspect SET SCHEMA public;
et il ne le permettra pas, produisant l'erreur suivante
ERROR: cannot remove dependency on schema pg_catalog because it is a system object
SQL state: 0A000
Euh oh! Eh bien, ça va que ça ne me laisse pas bouger. Je peux simplement le récupérer dans le schéma public en le supprimant et en le recréant, non? ...
DROP EXTENSION pageinspect;
CREATE EXTENSION pageinspect;
OK bien. De retour à sa place dans le schéma public, les fonctions sont toujours accessibles à tous les schémas de la base de données.
TL, DR; Utilisez simplement le schéma public par défaut pour les extensions.