On Fri, Jul 11, 2014 at 4:55 AM, Stephen Frost <sfr...@snowman.net> wrote: > On Thursday, July 10, 2014, Robert Haas <robertmh...@gmail.com> wrote: >> On Wed, Jul 9, 2014 at 2:13 AM, Stephen Frost <sfr...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers