Re: RLS Design
От | Stephen Frost |
---|---|
Тема | Re: RLS Design |
Дата | |
Msg-id | CAOuzzgqJXoC4U5dzpa7gxoX3pn9sAFKZJ+EcQqyoDQF7yEijFQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: RLS Design (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: RLS Design
|
Список | pgsql-hackers |
On Thursday, July 10, 2014, Robert Haas <robertmhaas@gmail.com> wrote:
On Wed, Jul 9, 2014 at 2:13 AM, Stephen Frost <sfrost@snowman.net> wrote:
> Yes, this would be possible (and is nearly identical to the original
> patch, except that this includes per-role considerations), however, my
> thinking is that it'd be simpler to work with policy names rather than
> sets of quals, to use when mapping to roles, and they would potentially
> be useful later for other things (eg: for setting up which policies
> should be applied when, or which should be OR' or AND"d with other
> policies, or having groups of policies, etc).
Hmm. I guess that's reasonable. Should the policy be a per-table
object (like rules, constraints, etc.) instead of a global object?
You could do:
ALTER TABLE table_name ADD POLICY policy_name (quals);
ALTER TABLE table_name POLICY FOR role_name IS policy_name;
ALTER TABLE table_name DROP POLICY policy_name;
Right, I was thinking they would be per table as they would specifically provide a name for a set of quals, and quals are naturally table-specific. I don't see a need to have them be global- that had been brought up before with the notion of applications picking their policy, but we could also add that later through another term (eg: contexts) which would then map to policies or similar. We could even extend policies to be global by mapping existing per-table ones to be global if we really needed to...
My feeling at the moment is that having them be per-table makes sense and we'd still have flexibility to change later if we had some compelling reason to do so.
Thanks!
Stephen
В списке pgsql-hackers по дате отправления: