Enabling column-level security/working with roles
In this section, I want to onboard you to column-level security (CLS). This could probably fill a chapter on its own. While most people can live well without CLS, this section will allow you to decide whether you want to implement it.
Understanding CLS semantically is actually simple. You can define which database roles will be able to perform which operations on which columns. For instance, in a table such as service_users, you could define that a specific role can only read (SELECT) the id column. Trying to select anything else from that table will lead to failure then. CLS, being column-based, can be applied to SELECT, UPDATE, and INSERT (columns cannot be deleted; hence, DELETE always refers to a row that you want to control with RLS policies, not CLS).
Let’s say we wanted the tickets table to only allow you to update the assignee column with CLS. First, we would have to revoke all UPDATE rights on that table to be...
