Re: [RFC] Interface of Row Level Security - Mailing list pgsql-hackers

From Yeb Havinga
Subject Re: [RFC] Interface of Row Level Security
Date
Msg-id 4FC71E0A.8070500@gmail.com
Whole thread Raw
In response to Re: [RFC] Interface of Row Level Security  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Responses Re: [RFC] Interface of Row Level Security
List pgsql-hackers
On 2012-05-30 21:26, Kohei KaiGai wrote:
> If we would have an "ideal optimizer", I'd still like the optimizer to
> wipe out redundant clauses transparently, rather than RLSBYPASS
> permissions, because it just controls all-or-nothing stuff.
> For example, if tuples are categorized to unclassified, classified or
> secret, and RLS policy is configured as:
>    ((current_user IN ('alice', 'bob') AND X IN ('unclassified',
> 'classified')) OR (X IN 'unclassified)),
> superuser can see all the tuples, and alice and bob can see
> up to classified tuples.
> Is it really hard to wipe out redundant condition at planner stage?
> If current_user is obviously 'kaigai', it seems to me the left-side of
> this clause can be wiped out at the planner stage.

The query's RLS policy would be simpler if the RLS policy function that 
returns the WHERE clause would take the user as argument, so its result 
does not contain user conditionals.

IF (current_user IN ('alice', 'bob')
THEN  RETURN X IN ('unclassified', 'classified'))
ELSE  RETURN X IN ('unclassified')
END IF;


regards,
Yeb




pgsql-hackers by date:

Previous
From: Devrim GÜNDÜZ
Date:
Subject: Re: Uppercase tab completion keywords in psql?
Next
From: Heikki Linnakangas
Date:
Subject: Re: FailedAssertion("!(PrivateRefCount[i] == 0)", File: "bufmgr.c", Line: 1741