On Friday, July 11, 2014, Robert Haas <> wrote:

> On Fri, Jul 11, 2014 at 4:55 AM, Stephen Frost <
> <javascript:;>> wrote:
> > 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.

Fair enough. My thinking was we'd come up with a way to map them (eg:
table_policy), but I do agree that changing it later would really suck and
having them be per-table makes a lot of sense.

> 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.

Agreed and I believe this is more-or-less what I had proposed up-thread
(not at a computer at the moment). I hope to have a chance to review and
update the design and flush out the catalog definition this weekend.



Reply via email to