PostgreSQL

PostgreSQL Change ManagementPostgreSQL Change Management

PostgreSQL betikleri sözdizimi ağacına dönüştürülerek çözümlenir. Aynı yönetişim akışı, aynı kural seti, PostgreSQL'e uyarlanmış karşılıklarıyla çalışır. PostgreSQL scripts are analysed by turning them into a syntax tree. The same governance flow and the same rule set apply, through equivalents adapted to PostgreSQL.

PostgreSQL tarafında ne yapılıyorWhat happens on the PostgreSQL side

AST tabanlı ayrıştırmaAST based parsing

Betik, PostgreSQL dilbilgisine göre bir ağaca dönüştürülür ve kurallar bu ağaç üzerinde çalışır. Tırnaklı nesne adları, şema önekleri ve iç içe sorgulardaki hedefler doğru konumla birlikte raporlanır.The script is turned into a tree according to PostgreSQL grammar, and the rules run on that tree. Quoted identifiers, schema prefixes and targets inside nested queries are reported with their correct position.

Dialect karşılıklarıDialect equivalents

Kural setindeki her madde her veritabanında birebir aynı şekilde ifade edilmez. Bir kuralın hangi veritabanı tiplerinde geçerli olduğu tanımlıdır; PostgreSQL'de karşılığı olmayan bir kural o tarafta hiç çalışmaz, karşılığı olan kural PostgreSQL'e uygun biçimde uygulanır.Not every item in the rule set is expressed identically on every database. Each rule declares the database types it applies to; a rule with no PostgreSQL equivalent simply does not run there, and one that does have an equivalent is applied the PostgreSQL way.

Aynı koruma kalıplarıThe same protective patterns

Kritik nesne erişimi ve şema değişikliği, WHERE içermeyen veri değişikliği, TRUNCATE, yetki değişikliği ve şema öneki eksikliği PostgreSQL tarafında da yakalanır.Critical object access and schema change, data changes without a WHERE clause, TRUNCATE, permission changes and missing schema prefixes are caught on PostgreSQL as well.

Geri alma ve denemeRollback and trial

Geri alma betiği üretimi PostgreSQL için de vardır. Betik, üretime dokunmadan izole bir sunucuda denenebilir ve sonuç talebe iliştirilir.Rollback script generation exists for PostgreSQL too. A script can be tried on an isolated server without touching production, and the result is attached to the request.

Aynı akış, tek fark dilbilgisiThe same flow, only the grammar differs

Bir talebin yolu veritabanı tipine göre değişmez: doğrulama, risk bandı, politika, onay, çalıştırma ve denetim. Değişen tek şey, betiği hangi ayrıştırıcının çözümlediğidir.

The path of a request does not change with the database type: validation, risk band, policy, approval, execution and audit. The only thing that changes is which parser analyses the script.

Ayrıştırıcı, talebin hedef sunucusundaki veritabanı tipinden seçilir. Bu yüzden karışık ortamlarda onay kuralınız tek kalır: SQL Server için ayrı, PostgreSQL için ayrı bir yönetişim modeli kurmanız gerekmez.

The parser is chosen from the database type of the request's target server. In a mixed estate this keeps your approval rule single: you do not need one governance model for SQL Server and another for PostgreSQL.

Kapsam notu: PostgreSQL burada yönetilen hedef veritabanıdır. Ürünün kendi kayıt veritabanı SQL Server üzerinde çalışır.

Scope note: PostgreSQL is a managed target database here. The product keeps its own records on SQL Server.

EkranlarScreens

Sunucu yönetimi ekranı: PostgreSQL bağlantısı, port ve ortam etiketi
Sunucu tanımıServer definition Veritabanı tipi seçilince port varsayılanı da güncellenir. Choosing the database type also updates the default port.
SQL standartları ekranı: kuralın geçerli olduğu veritabanı tipleri
Kural kapsamıRule scope Her kuralın hangi veritabanlarında çalıştığı tanımlı. Each rule declares which databases it runs on.
Nesne değişiklik geçmişi ekranı: hedef veritabanından okunan kayıtlar
Nesne geçmişiObject history Veri hedef veritabanının kendisinden okunur. The data is read from the target database itself.