On Fri, Jul 11, 2014 at 4:55 AM, Stephen Frost <sfrost@snowman.net> wrote:
> 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.
I don't think you can really change it later. If policies are
per-table, then you could have a policy p1 on table t1 and also on
table t2; if they become global objects, then you can't have p1 in two
places. I hope I'm not beating a dead horse here, but changing syntax
after it's been released is very, very hard.
But that's not an argument against doing it this way; I think
per-table policies are probably simpler and better here. It means,
for example, that policies need not have their own permissions and
ownership structure - they're part of the table, just like a
constraint, trigger, or rule, and the table owner's permissions
control. I like that, and I think our users will, too.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
