I need strict control of the reading and writing of my Postgres data. Updatable views have always provided very good, strict, control of the reading of my data and allows me to add valuable computed columns. With Postgres 9.5 row level security has introduced a new and powerful way to control my data. But I can't use both technologies views, and row level security together. Why?
相关问题
- SQL join to get the cartesian product of 2 columns
- sql execution latency when assign to a variable
- Difference between Types.INTEGER and Types.NULL in
- php PDO::FETCH_ASSOC doesnt detect select after ba
- Bulk update SQL Server C#
Basically because it wasn't possible to retroactively change how views work. I'd like to be able to support
SECURITY INVOKER
(or equivalent) for views but as far as I know no such feature presently exists.You can filter access to the view its self with row security normally.
The tables accessed by the view will also have their row security rules applied. However, they'll see the
current_user
as the view creator because views access tables (and other views) with the rights of the user who created/owns the view.Maybe it'd be worth raising this on pgsql-hackers if you're willing to step in and help with development of the feature you need, or pgsql-general otherwise?
That said, while views access tables as the creating user and change
current_user
accordingly, they don't prevent you from using custom GUCs, thesession_user
, or other contextual information in row security policies. You can use row security with views, just not (usefully) to filter based oncurrent_user
.