PostgreSQL doesn't have row-level declarative security (yet, there's ongoing work into it) so if you can't just create a view - say, if you have many different people who need this access - you will probably need a SECURITY DEFINER
helper function or trigger.
You've got a couple of options:
- Write a
SECURITY DEFINER
function that lets them make only the permitted changes and limit their access to the table to SELECT
, revoking UPDATE
, DELETE
, TRUNCATE
and INSERT
rights; or
- write a trigger that tries to restrict them from making changes you don't want them to make and
GRANT
them write access to the table.
Of the two, the function and restricted rights approach is by far the safest option so long as you follow the SECURITY DEFINER
secure coding guidelines set above - setting search_path
for the function, avoiding dynamic SQL (EXECUTE
) with string substitutions, etc.
The view approach given above can work quite nicely if it's a view that filters by current_user
. You may also want to look at the new SECURITY BARRIER
views; see this post for a useful discussion of them.