Re: Postgres trigger side-effect is occurring out of order with row-level security select policy

2018-10-02 Thread Carl Sverre
Dean, Thank you for the pointer towards visibility/volatility. I think that completely explains the effect that I am seeing in my repro. I experimented with using a VOLATILE function for the SELECT RLS using statement and while it completely solves my issue, it incurs too high a cost for query

Re: Postgres trigger side-effect is occurring out of order with row-level security select policy

2018-10-02 Thread Dean Rasheed
On Mon, 1 Oct 2018 at 21:45, Carl Sverre wrote: > Dean, > Thank you for the pointer towards visibility/volatility. I think that > completely explains the effect that I am seeing in my repro. I experimented > with using a VOLATILE function for the SELECT RLS using statement and while > it

Re: Postgres trigger side-effect is occurring out of order with row-level security select policy

2018-10-01 Thread Carl Sverre
Thank you for the detailed report Charles. I think you may be missing the “returning id” clause in the insert. Can you verify it works when you use “returning id”? Thanks! On Sun, Sep 30, 2018 at 7:57 PM Charles Clavadetscher (SwissPUG) < clavadetsc...@swisspug.org> wrote: > Hello > > On

Re: Postgres trigger side-effect is occurring out of order with row-level security select policy

2018-10-01 Thread Carl Sverre
Thanks for the initial results. Can you check that you are not using super permissions and are enabling row security when running the test? Super ignores row security. Also yes, I forgot to add the policy names, sorry about that. On Sun, Sep 30, 2018 at 1:34 AM Charles Clavadetscher (SwissPUG) <

Re: Postgres trigger side-effect is occurring out of order with row-level security select policy

2018-09-30 Thread Charles Clavadetscher (SwissPUG)
An addition On 01.10.2018 05:18:15, Charles Clavadetscher (SwissPUG) wrote: Hello On 01.10.2018 05:00:02, Carl Sverre wrote: Thank you for the detailed report Charles. I think you may be missing the “returning id” clause in the insert. Can you verify it works when you use “returning id”?

Re: Postgres trigger side-effect is occurring out of order with row-level security select policy

2018-09-30 Thread Charles Clavadetscher (SwissPUG)
Hello On 01.10.2018 05:00:02, Carl Sverre wrote: Thank you for the detailed report Charles. I think you may be missing the “returning id” clause in the insert. Can you verify it works when you use “returning id”? Thanks! [Charles] : You are right: testuser@charles.localhost=> INSERT INTO a

Re: Postgres trigger side-effect is occurring out of order with row-level security select policy

2018-09-30 Thread Charles Clavadetscher (SwissPUG)
Hello On 30.09.2018 23:31:32, Adrian Klaver wrote: On 9/30/18 1:13 PM, Carl Sverre wrote: > Thanks for the initial results. Can you check that you are not using > super permissions and are enabling row security when running the test? > Super ignores row security. Yeah, big oops on my part, I

Re: Postgres trigger side-effect is occurring out of order with row-level security select policy

2018-09-30 Thread Adrian Klaver
On 9/30/18 1:13 PM, Carl Sverre wrote: Thanks for the initial results. Can you check that you are not using super permissions and are enabling row security when running the test? Super ignores row security. Yeah, big oops on my part, I was running as superuser. Running as non-superuser

Re: Postgres trigger side-effect is occurring out of order with row-level security select policy

2018-09-30 Thread Charles Clavadetscher (SwissPUG)
Hello On 29.09.2018 20:24:45, Adrian Klaver wrote: On 9/28/18 11:35 PM, Carl Sverre wrote: > *Context* > I am using row-level security along with triggers to implement a pure > SQL RBAC implementation. While doing so I encountered a weird behavior > between INSERT triggers and SELECT row-level

Re: Postgres trigger side-effect is occurring out of order with row-level security select policy

2018-09-29 Thread Adrian Klaver
On 9/28/18 11:35 PM, Carl Sverre wrote: *Context* I am using row-level security along with triggers to implement a pure SQL RBAC implementation. While doing so I encountered a weird behavior between INSERT triggers and SELECT row-level security policies. *Question* I have posted a very