in my PostgreSQL database I setup some triggers to prevent DELETE and EDIT operations (the triggers make sure that these operations lead to nothing). However, I'm wondering how safe these triggers are? Is it possible to circumvent these triggers and delete data by trying to illegally hack the data?


Security in ANSI relational databases is normally based on layers and one of those is role based access. A business case that no one will ever need to delete or edit data in some tables will probably need to be revised when someone makes an oopsie and bad data is entered.

Any code that is written whether it's in a trigger or stored procedure has a chance of being misused but this requires access. A better solution than writing triggers that prevent basic operations on data is to control access and permissions by creating roles for each type of user and granting permissions appropriate to those roles.


They are not very safe to do what you want as they can be disabled/deleted if the user has the correct privileges. If you are wanting to prevent users from updating/deleting data you should do that by preventing them from having the permissions to perform those actions in the first place. If a user is able to "hack" to get those permissions they will be notified of the triggers that prevent updates/deletes and either disable/delete those before doing what they want to (and what you where trying to prevent)


I'd say that such a trigger is absolutely safe provided you take care of two things:

  1. The code has no bugs.

  2. The user is no superuser and does not belong to the role that owns the table.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.