É recomendável instalar extensões no esquema pg_catalog?


Respostas:


16

Não instale extensões para pg_catalog(a menos que é o seu padrão: muito poucas extensões são concebidos dessa forma), porque você não mexa com catálogo do sistema, sempre . @ Chris demonstra uma razão para isso. Há outros.

No entanto, o esquema "público" não é de forma alguma especial . É apenas o esquema padrão pré-instalado nas distribuições padrão, para que possamos começar imediatamente. Alguns administradores de banco de dados não usam o esquema "público", outros até o excluem.

CREATE EXTENSIONnão é afiliado ao esquema "público". Ele é instalado no esquema atual, a menos que seja instruído de outra forma - exceto que algumas extensões têm um esquema predefinido (como PGQ / Londiste ). A documentação:

schema_name

O nome do esquema no qual instalar os objetos da extensão, uma vez que a extensão permite que seu conteúdo seja realocado. O esquema nomeado já deve existir. Se não especificado, e o arquivo de controle da extensão também não especificar um esquema, o esquema de criação de objeto padrão atual será usado .

Lembre-se de que a extensão em si não é considerada como estando em nenhum esquema: as extensões têm nomes não qualificados que devem ser exclusivos em todo o banco de dados. Mas objetos pertencentes à extensão podem estar dentro de esquemas.

Negrito ênfase minha.
Decida como gerenciar usuários, esquemas e search_path:

Depois, decida onde instalar as extensões. Você pode instalar em qualquer esquema de sua escolha e incluir esse esquema no padrão search_pathpara todos os usuários ou apenas para alguns ou nenhum usuário (para que sejam necessárias referências qualificadas). Tudo depende do que você deseja alcançar.
Faça o que fizer, fique consistente.

Eu gosto de instalar extensões (que permitem) em um esquema de "extensões" dedicado, que eu incluo no padrão search_path depois de "public" (e "$ user" - se você usar isso). Ajuda com uma separação limpa de minhas próprias funções públicas e outros objetos públicos. Minha configuração em postgresql.conf:

search_path = "$user",public,extensions

Ou:

search_path = public,extensions

E eu instalo extensões com:

CREATE EXTENSION some_extension SCHEMA extensions;

Uma coisa a ser observada: dessa forma, você pode "ocultar" objetos (não qualificados) no extensionsesquema atrás de objetos com o mesmo nome (e parâmetros) no publicesquema.

Relacionado:


ok é plpgsqlextensão então de alguma forma uma exceção a esta regra? Cada instalação tenho visto tem esta extensão em pg_catalog
zam6ak

@ zam6ak: Sim, o plpgsql é um caso um pouco especial: Citando o manual :In PostgreSQL 9.0 and later, PL/pgSQL is installed by default. However it is still a loadable module, so especially security-conscious administrators could choose to remove it.
Erwin Brandstetter

11
O plv8 também se instala pg_catalog. (Isso gera um erro se você tentar alterá-lo.) Esse talvez seja um padrão para instalar extensões de linguagem procedural para funções?
jpmc26

6

A instalação de extensões no pg_catalog, até onde sei, não é aconselhável. Você deve usar o publicesquema padrão , que também está no search_pathpadrão.

Por quê?

Como exemplo, trabalharei com a pageinspectextensão que eu já criei no publicesquema. Todas as funções são, por padrão, acessíveis a todos os esquemas no banco de dados, se estiverem localizadas no publicesquema.

Agora, tento movê-lo para o pg_catalogesquema, usando

ALTER EXTENSION pageinspect SET SCHEMA pg_catalog;

e funciona muito bem.

Mas...

Tente movê-lo novamente, de volta ao publicesquema usando

ALTER EXTENSION pageinspect SET SCHEMA public;

e não permitirá, produzindo o seguinte erro

ERROR: cannot remove dependency on schema pg_catalog because it is a system object
SQL state: 0A000

Oh! Bem, tudo bem que não me deixe mexer. Posso recuperá-lo novamente no publicesquema, soltando-o e recriando, certo? ...

DROP EXTENSION pageinspect;
CREATE EXTENSION pageinspect;

Tudo bem. De volta ao lugar certo no publicesquema, e as funções ainda estão acessíveis a todos os esquemas no banco de dados.

TL, DR; Basta usar o publicesquema padrão para extensões.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.