Poiché gli oggetti nello pg_catalogschema sono implicitamente nei search_path( documenti ), si consiglia di installare le estensioni in quello schema?

Non installare estensioni pg_catalog(a meno che non è il loro difetto: pochissime le estensioni sono progettate in questo modo), perché non si scherza con il catalogo del sistema, mai . @Chris dimostra uno dei motivi per cui. Ce ne sono altri

Tuttavia, lo schema "pubblico" non è in alcun modo speciale . È solo lo schema predefinito preinstallato nelle distribuzioni standard, quindi possiamo iniziare subito. Alcuni amministratori DB non usano affatto lo schema "pubblico", altri addirittura lo eliminano.

CREATE EXTENSIONnon è affiliato allo schema "pubblico". Si installa nello schema corrente se non diversamente specificato - tranne che per alcune estensioni hanno uno schema preimpostato (come PGQ / Londiste ). La documentazione:

schema_name

Il nome dello schema in cui installare gli oggetti dell'estensione, dato che l'estensione consente di spostare il suo contenuto. Lo schema denominato deve già esistere. Se non specificato e il file di controllo dell'estensione non specifica nemmeno uno schema, viene utilizzato lo schema di creazione dell'oggetto predefinito corrente .

Ricorda che l'estensione stessa non è considerata all'interno di alcuno schema: le estensioni hanno nomi non qualificati che devono essere univoci a livello di database. Ma gli oggetti appartenenti all'estensione possono trovarsi all'interno di schemi.

Enorme enfasi sulla mia.
Decidi come gestire utenti, schemi e search_path:

• In che modo il percorso di ricerca influenza la risoluzione dell'identificatore e lo "schema corrente"

Quindi decidere dove installare le estensioni. È possibile installare su qualsiasi schema di propria scelta e includere quello schema nel valore predefinito search_pathper tutti gli utenti o solo per alcuni o nessun utente (quindi sono necessari riferimenti qualificati). Tutto dipende da cosa vuoi ottenere.
Qualunque cosa tu faccia, rimani coerente.

Mi piace installare le estensioni (che lo consentono) in uno schema "estensioni" dedicato, che includo nel valore predefinito search_path dopo "pubblico" (e "$ utente" - se lo usi). Aiuta a una netta separazione delle mie funzioni pubbliche e di altri oggetti pubblici. La mia impostazione in postgresql.conf:

search_path = "$user",public,extensions

O:

search_path = public,extensions

E installo le estensioni con:

CREATE EXTENSION some_extension SCHEMA extensions;

Una cosa da notare: in questo modo è possibile "nascondere" oggetti (non qualificati) nello extensionsschema dietro oggetti con lo stesso nome (e parametri) nello publicschema.

Relazionato:

• Il modo migliore per installare hstore su più schemi in un database Postgres?
• Come posso falsificare inet_client_addr () per i test unitari in PostgreSQL?

L'installazione di estensioni in pg_catalog, per quanto ne so, non è consigliata. È necessario utilizzare lo publicschema predefinito , anch'esso presente search_pathper impostazione predefinita.

Perché?

Ad esempio, lavorerò con l' pageinspectestensione che ho già creato all'interno dello publicschema. Tutte le funzioni sono, per impostazione predefinita, accessibili a tutti gli schemi nel database se si trovano nello publicschema.

Ora provo a spostarlo nello pg_catalogschema, usando

ALTER EXTENSION pageinspect SET SCHEMA pg_catalog;

e funziona benissimo.

Ma...

Prova a spostarlo di nuovo, torna allo publicschema usando

ALTER EXTENSION pageinspect SET SCHEMA public;

e non lo permetterà, producendo il seguente errore

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

Uh Oh! Bene, va bene che non mi permette di spostarlo. Posso semplicemente riportarlo nello publicschema rilasciandolo e ricreando, giusto? ...

DROP EXTENSION pageinspect;
CREATE EXTENSION pageinspect;

Ok bene. Di nuovo al suo posto nello publicschema, e le funzioni sono ancora accessibili a tutti gli schemi nel database.

TL, DR; Usa lo publicschema predefinito per le estensioni.