Re: [HACKERS] [COMMITTERS] pgsql: Row-Level Security Policies (RLS)

2015-07-30 Thread Dean Rasheed
On 30 July 2015 at 01:35, Joe Conway m...@joeconway.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/01/2015 02:21 AM, Dean Rasheed wrote: While going through this, I spotted another issue --- in a DML query with additional non-target relations, such as UPDATE t1 .. FROM t2

Re: [HACKERS] [COMMITTERS] pgsql: Row-Level Security Policies (RLS)

2015-07-30 Thread Joe Conway
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/30/2015 06:52 AM, Dean Rasheed wrote: On 30 July 2015 at 01:35, Joe Conway m...@joeconway.com wrote: On 06/01/2015 02:21 AM, Dean Rasheed wrote: While going through this, I spotted another issue --- in a DML query with additional non-target

Re: [HACKERS] [COMMITTERS] pgsql: Row-Level Security Policies (RLS)

2015-07-29 Thread Joe Conway
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/01/2015 02:21 AM, Dean Rasheed wrote: While going through this, I spotted another issue --- in a DML query with additional non-target relations, such as UPDATE t1 .. FROM t2 .., the old code was checking the UPDATE policies of both t1 and

Re: [HACKERS] [COMMITTERS] pgsql: Row-Level Security Policies (RLS)

2015-06-01 Thread Dean Rasheed
On 28 May 2015 at 08:51, Stephen Frost sfr...@snowman.net wrote: * Dean Rasheed (dean.a.rash...@gmail.com) wrote: Actually I think a new boolean field is unnecessary, and probably the policy_id field is too. Re-reading the code in rowsecurity.c, I think it could use a bit of refactoring.

Re: [HACKERS] [COMMITTERS] pgsql: Row-Level Security Policies (RLS)

2015-05-28 Thread Dean Rasheed
On 27 May 2015 at 14:51, Stephen Frost sfr...@snowman.net wrote: On 27 May 2015 at 02:42, Stephen Frost sfr...@snowman.net wrote: Now, looking at the code, I'm actually failing to see a case where we use the RowSecurityPolicy-policy_name.. Perhaps *that's* what we should be looking to

Re: [HACKERS] [COMMITTERS] pgsql: Row-Level Security Policies (RLS)

2015-05-28 Thread Stephen Frost
Dean, * Dean Rasheed (dean.a.rash...@gmail.com) wrote: On 27 May 2015 at 14:51, Stephen Frost sfr...@snowman.net wrote: On 27 May 2015 at 02:42, Stephen Frost sfr...@snowman.net wrote: Now, looking at the code, I'm actually failing to see a case where we use the

Re: [HACKERS] [COMMITTERS] pgsql: Row-Level Security Policies (RLS)

2015-05-27 Thread Stephen Frost
Dean, * Dean Rasheed (dean.a.rash...@gmail.com) wrote: On 27 May 2015 at 02:42, Stephen Frost sfr...@snowman.net wrote: Now, looking at the code, I'm actually failing to see a case where we use the RowSecurityPolicy-policy_name.. Perhaps *that's* what we should be looking to remove? If

Re: [HACKERS] [COMMITTERS] pgsql: Row-Level Security Policies (RLS)

2015-05-26 Thread Stephen Frost
Alvaro, * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: Stephen Frost wrote: * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: What do we need RowSecurityPolicy-policy_id for? It seems to me that it is only used to determine whether the policy is the default deny one, so that it

Re: [HACKERS] [COMMITTERS] pgsql: Row-Level Security Policies (RLS)

2015-05-26 Thread Stephen Frost
Alvaro, * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: What do we need RowSecurityPolicy-policy_id for? It seems to me that it is only used to determine whether the policy is the default deny one, so that it can later be removed if a hook adds a different one. This seems contrived as

Re: [HACKERS] [COMMITTERS] pgsql: Row-Level Security Policies (RLS)

2015-05-26 Thread Alvaro Herrera
Stephen Frost wrote: Alvaro, * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: What do we need RowSecurityPolicy-policy_id for? It seems to me that it is only used to determine whether the policy is the default deny one, so that it can later be removed if a hook adds a different one.

Re: [HACKERS] [COMMITTERS] pgsql: Row-Level Security Policies (RLS)

2015-05-22 Thread Alvaro Herrera
Stephen Frost wrote: Row-Level Security Policies (RLS) What do we need RowSecurityPolicy-policy_id for? It seems to me that it is only used to determine whether the policy is the default deny one, so that it can later be removed if a hook adds a different one. This seems contrived as well as