Re: [GENERAL] Can row level security policies also be implemented for views?
Yes it probably could be solved by this. Just a trigger which replaces SELECT right? On Wed, Dec 2, 2015 at 6:01 PM Jim Nasby wrote: > On 12/2/15 4:59 PM, Caleb Meredith wrote: > > What is an SRF? > > Set returning function. > > CREATE FUNCTION srf() RETURNS SETOF pg_class LANGUAGE sql AS 'SELECT * > FROM pg_class'; > -- > Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX > Experts in Analytics, Data Architecture and PostgreSQL > Data in Trouble? Get it in Treble! http://BlueTreble.com >
Re: [GENERAL] Can row level security policies also be implemented for views?
What is an SRF? On Wed, Dec 2, 2015 at 5:46 PM Jim Nasby wrote: > On 11/25/15 7:40 AM, Stephen Frost wrote: > >> It seems easy conceptually, RLS just adds a WHERE clause to queries if > I'm > >> >not mistaken, and conceptually a view is just a query. The CURRENT_USER > >> >issue is valid, but personally it's not too big for me as most auth is > done > >> >through database parameters. > > The hard part is making sure that what happens when there are policies > > on views actually makes sense and works as users expect. > > Could this potentially be worked around by having a view that pulls from > an SRF? Possibly an SRF that's using a dynamically constructed query? > -- > Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX > Experts in Analytics, Data Architecture and PostgreSQL > Data in Trouble? Get it in Treble! http://BlueTreble.com >
[GENERAL] Can row level security policies also be implemented for views?
I'm developing an application where strict control of my data is important. Views allow me to build a strict custom reading experience, allowing me to add computed columns and hide private and metadata columns. Row level security allows me strict write control of my data. However, I can't use both technologies together, why? It seems easy conceptually, RLS just adds a WHERE clause to queries if I'm not mistaken, and conceptually a view is just a query. The CURRENT_USER issue is valid, but personally it's not too big for me as most auth is done through database parameters.