From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Adam Brightwell <adam(dot)brightwell(at)crunchydatasolutions(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Yeb Havinga <yeb(dot)havinga(at)portavita(dot)nl> |
Subject: | Re: RLS Design |
Date: | 2014-07-11 08:55:53 |
Message-ID: | CAOuzzgqJXoC4U5dzpa7gxoX3pn9sAFKZJ+EcQqyoDQF7yEijFQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thursday, July 10, 2014, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Jul 9, 2014 at 2:13 AM, Stephen Frost <sfrost(at)snowman(dot)net
> <javascript:;>> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2014-07-11 09:08:48 | pg_receivexlog and replication slots |
Previous Message | Etsuro Fujita | 2014-07-11 08:45:33 | No exact/lossy block information in EXPLAIN ANALYZE for a bitmap heap scan |