Utilizing silent resets to avoid data manipulation

Within this book, we’ve written quite a few RLS policies and learned that access via RLS means access on a row. So, if I have UPDATE rights on a table, I can update whatever column I want within that row.

You can obviously extend an RLS expression to enforce certain limitations on columns, but have you ever thought about how to ensure that a created_at column stays the same and cannot be changed during an update? Have a think.

So, what’s your solution for this? Maybe you were thinking about a way to somehow retrieve the existing created_at value and then compare it to the newly set value. However, trying to integrate such pseudo-column-level security within row-level security can be messy, extremely complex, or even simply impossible.

One solution to this problem is using actual column-level security, which we will discuss further in the next section, but sometimes, all you need is what I call a silent reset...