Re: RLS Design
От | Stephen Frost |
---|---|
Тема | Re: RLS Design |
Дата | |
Msg-id | CAOuzzgrxiXJkt1nkxH+TFhy8OHRffBpg-CeczcKzmXE_LsygLQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: RLS Design (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
Robert,
On Friday, July 11, 2014, Robert Haas <robertmhaas@gmail.com> wrote:
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.
On Friday, July 11, 2014, Robert Haas <robertmhaas@gmail.com> wrote:
On Fri, Jul 11, 2014 at 4:55 AM, Stephen Frost <sfrost@snowman.net> 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.
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.
Thanks!
Stephen
В списке pgsql-hackers по дате отправления: