Skip to main content

Tablo Yetkilerinin Başka Tabloya Tanımlanması

Merhaba,

Daha önce aldığım notun kaybolmaması adına bu yazıyı yazmak istedim. Paylaşacağım bu yazı içeriğinde yapılan işlemlerin sonucuna farklı yollardan da ulaşılabilir tabi. 

Tabloların belirli kullanıcılar tarafından erişilebilir olması için kullanıcıların tablolar üzerinde yetkiye ihtiyaçları vardır. Bunun için Postgres, GRANT komutu kullanılır. GRANT ile ilgili detaylı bilgiye buradan ulaşabilirsiniz.

Bir tablo üzerinde birden fazla kullanıcının farklı yetki tipinde yetkiye sahip olması olağandır. Belirli tablo üzerindeki kullanıcı yetkilerini aşağıdaki script ile görebilirsiniz.

SELECT grantor, grantee, privilege_type  
FROM information_schema.role_table_grants 
WHERE table_schema ='public' 
AND table_name = 'test_table';
 
Yeni bir tablo eklediniz ve mevcut tablonuzun üzerindeki kullanıcı yetkilerinin birebir yeni tablonuzda da olmasını isterseniz yukarıdaki scripti biraz daha değiştirerek GRANT scriptini SQL ile oluşturabilirsiniz. 

Öncesinde yukarıdaki scripti biraz daha değiştirelim ve kullanıcı bazında değil, yetki tipi (privilege_type) bazında gruplayalım.

SELECT privilege_type, string_agg(grantee, ', ') 
FROM information_schema.role_table_grants 
WHERE table_schema='public'  
AND table_name = 'test_table
GROUP BY privilege_type 
ORDER BY 1,2;

Artık elimizde SELECT, UPDATE, DELETE gibi kullanıcı gruplarının sahip olduğu yetkileri, yetki bazında listeledik. Şimdi son adım olan GRANT scriptini SQL ile oluşturulması adımı yazmak kaldı. Onu da aşağıdaki gibi oluşturabiliriz.

SELECT
'GRANT ' || privilege_type || ' ON TABLE ' || 'prvt' || '.' || 'new_table' || ' TO ' || string_agg(grantee, ', ') || ';'FROM information_schema.role_table_grants 
WHERE table_schema ='public'  
AND table_name = 'test_table' 
GROUP BY privilege_type 
ORDER BY 1;
 

Sevgiler,

Comments

Popular posts from this blog

PGConf Europe 2018 Güncesi 1

Merhaba, Diğer tüm veritabanları arasında en popüler açık kaynak kodlu veritabanı olan PostgreSQL, tüm yıl boyunca farklı ülkelerde bir çok konferansa sahiplik yapmaktadır. En bilinenleri PGDay ve PGConf'dur. Ayrıca her yıl 2 Şubatta Brüksel’de yapılan FOSDEM etkinliğinde de PostgreSQL konuşmalarının yapıldığı bir oturum mutlaka olmaktadır. PostgreSQL etkinlik detaylarına bu linkten ulaşabilirsiniz. Bu yıl ki PGConf Europe konferansı Lizbon'da yapıldı. Konferansla ilgili izlenimlerimi, yaptığım neredeyse 6 günlük yolculuğun en başından tüm detaylarıyla birlikte paylaşmak istiyorum. Yolculuğumuz sevgili Seda ile birlikte Atatürk Havalimanı’ndan sabah 07:30’da Lizbon’a direk uçuşla başladı.  Hava şahaneydi ve uçuşumuz konforlu geçti. Koltuğumuz cam kenarı ve uçağın kanadının hemen yanındaydı (benim favori koltuklarım 24, 25, 26, 27 ve 28. sıradakiler) ve biz 27. sıradaydık. Bol bol resim çektik bulutların üstündeyken ve uçak kanatlı olanlardan.  Lizbon’a vardığımı...

PostgreSQL High Availability - Patroni 2

Patroni kurulumuyla ilgili oldukça fazla kaynak bulunmakta fakat kurulum ve yönetimini beraber barındıran kaynağa denk gelmedim. Bu yazıda hem Patroni kurulumu hem de kurulum sonrası yönetimiyle alakalı detaylara ulaşabilirsiniz. PostgreSQL cluster'larının yönetimi için kullanılan Patroni ile ilgili temel bilgilerin yer aldığı Autofailover üzerine hazırladığım yazı serisine aşağıdaki linklerden erişebilirsiniz. PostgreSQL ve Autofailover PostgreSQL'de Autofailover ve Patroni 1 (Giriş) PostgreSQL'de Autofailover ve Patroni 2 (Kurulum, Konfigürasyon ve Yönetim) PostgreSQL'de Autofailover ve Patroni 3 (Mevcut PostgreSQL Cluster'inin Patroni'ye Geçirilmesi) Patroni, PostgreSQL veritabanlarının kurulumundan ve konfigürasyonundan sorumludur. Yani Patroni'yi kurduğumuz sunucular aynı zamanda Patroni ile kurulmuş PostgreSQL'leri barındıracak. Üç node'lu PostgreSQL ve üç node'lu ETCD cluster'larını oluşturacağım. Kuruluma önce üç no...

ERROR: pg_stop_backup still waiting for all required WAL segments to be archived

Hi, This error mention that WAL Segments can not be archived, so you need to check archive_command is right to archive WAL.  NOTICE: pg_stop_backup cleanup done, waiting for required WAL segments to be archived  WARNING: pg_stop_backup still waiting for all required WAL segments to be archived (60 seconds elapsed)  HINT: Check that your archive_command is executing properly. pg_stop_backup can be cancelled safely, but the database backup will not be usable without all the WAL segments. archive_command can be as bellow row in your postgres.conf file; archive_command = '/bin/cp %p /var/lib/pgsql/archive/%f' the most important thing is if there is a directory for /var/lib/pgsql/archive/%f side. Check it out and reload your config file or restart your Postgresql server. Loves,