Screens
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.
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.
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.
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.
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.
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.
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.
Scope note: PostgreSQL is a managed target database here. The product keeps its own records on SQL Server.