pg_catalogŞemadaki nesneler dolaylı olarak search_path( dokümanlar ) içinde olduğundan, bu şemaya uzantıların yüklenmesi önerilir mi?

Uzantıları yüklemeyin pg_catalog(bu varsayılan değilse: çok az sayıda uzantı bu şekilde tasarlanır), çünkü sistem kataloğuyla uğraşmazsınız . @Chris bunun bir nedeni olduğunu gösteriyor. Başkaları da var.

Ancak, "kamu" şeması hiçbir şekilde özel değildir . Bu, standart dağıtımlara önceden yüklenmiş olan varsayılan şemadır, böylece hemen başlayabiliriz. Bazı DB yöneticileri "genel" şemayı hiç kullanmaz, hatta bazıları siler.

CREATE EXTENSION"genel" şemaya bağlı değildir. Aksi belirtilmedikçe geçerli şemaya yüklenir - ancak bazı uzantıların önceden ayarlanmış bir şeması olması ( PGQ / Londiste gibi ). Dökümantasyon:

schema_name

Uzantının içeriğinin taşınmasına izin verdiği göz önüne alındığında, uzantının nesnelerinin yükleneceği şemanın adı. Adlandırılmış şema zaten var olmalıdır. Belirtilmezse ve uzantının kontrol dosyası da bir şema belirtmezse , geçerli varsayılan nesne oluşturma şeması kullanılır .

Uzantının kendisinin herhangi bir şemada kabul edilmediğini unutmayın: uzantılar, veritabanı genelinde benzersiz olması gereken kalifiye olmayan adlara sahiptir. Ancak uzantıya ait nesneler şemalar içinde olabilir.

Cesur vurgu benim.
Kullanıcıları, şemaları ve aşağıdakileri nasıl yöneteceğinize karar verin search_path:

• Search_path, tanımlayıcı çözünürlüğünü ve “geçerli şema” yı nasıl etkiler?

Ardından uzantıların nereye yükleneceğine karar verin. İstediğiniz herhangi bir şemaya yükleyebilir ve bu şemayı varsayılan search_patholarak tüm kullanıcılar için veya yalnızca bazı kullanıcılar için veya hiç kullanıcı için dahil edebilirsiniz (böylece nitelikli referanslar gerekir). Her şey neyi başarmak istediğinize bağlıdır.
Ne yaparsanız yapın, tutarlı olun.

Uzantıları (buna izin verir) "genel" (ve "$ user" - search_path sonra kullanırsanız) varsayılan dahil varsayılan bir "uzantıları" şemasına yüklemek istiyorum . Kendi ortak işlevlerimin ve diğer ortak nesnelerimin temiz bir şekilde ayrılmasına yardımcı olur. Benim ayarım postgresql.conf:

search_path = "$user",public,extensions

Veya:

search_path = public,extensions

Ve şu uzantıları yüklüyorum:

CREATE EXTENSION some_extension SCHEMA extensions;

Dikkat edilmesi gereken bir nokta: Bu şekilde extensionsşemadaki nesneleri (şemadaki niteliksiz) şemadaki aynı ada (ve parametrelere) sahip nesnelerin arkasına "gizleyebilirsiniz" public.

İlişkili:

• Bir Postgres veritabanında birden çok şemaya hstore kurmanın en iyi yolu?
• PostgreSQL'de birim testleri için inet_client_addr () yöntemini nasıl taklit edebilirim?

Uzantıları yüklemek pg_catalog, bildiğim kadarıyla tavsiye edilmiyor. Varsayılan publicşemada da bulunan varsayılan şemayı kullanmalısınız search_path.

Neden?

Örnek olarak, pageinspectdaha önce publicşemada oluşturduğum uzantıyla çalışacağım . Tüm işlevler, varsayılan olarak, publicşemada bulunuyorlarsa veritabanındaki tüm şemalar tarafından erişilebilir durumdadır .

Şimdi, pg_catalogşemaya taşıyarak

ALTER EXTENSION pageinspect SET SCHEMA pg_catalog;

ve gayet iyi çalışıyor.

Fakat...

Tekrar publickullanarak şemaya geri taşımaya çalışın.

ALTER EXTENSION pageinspect SET SCHEMA public;

ve buna izin vermez, aşağıdaki hatayı verir

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

Ah! Hareket ettirmeme izin vermeyecek bir sorun yok. Onu publicbırakıp yeniden oluşturarak şemaya geri alabilirim , değil mi? ...

DROP EXTENSION pageinspect;
CREATE EXTENSION pageinspect;

Tamam iyi. publicŞemada doğru yerde ve işlevler veritabanındaki tüm şemalar için hala erişilebilir.

TL, DR; publicUzantılar için varsayılan şemayı kullanmanız yeterlidir.