For the problem mentioned in the blog post — protecting roles — it's not possible to use event triggers because PostgreSQL doesn't fire[2] a DDL event for `CREATE/ALTER/DROP ROLE`.
If an event for role modification was added, then maybe the same could be accomplished with event triggers(perhaps in pure SQL). Though hooks will always be more strict, since you can enforce conditions by preloading the extension in C code, without custom SQL. Also, hooks can enforce a condition even in presence of superusers[3], something that event triggers can't because a superuser can drop them.
Not a 100% technically correct answer most likely but first look suggests they hook into the statement preprocessing pipeline. In the example, they’re hooking into the ALTER ROLE statement and deny execution if the role is a protected one. I don’t think this can be done with triggers without creating triggers on system tables and knowing the exact places where postgres would try to make changes. This seems to be an ott solution and probably a pretty bulletproof one.
Very timely article, I wonder if this works with yugabyte...
Check this line here[1]. That shows that Yugabyte also has the `ProcessUtility_hook`(same one used in the article) defined. It would be a matter of installing and loading the Supautils extension.
