On Thu, Jan 7, 2016 at 2:29 PM, Stephen Frost <sfr...@snowman.net> wrote: > Robert, > > * Robert Haas (robertmh...@gmail.com) wrote: > >> Apart from the issue of whether this is doomed for some architectural >> reason, it is not entirely clear to me that there's any consensus that >> we want this. I don't think that I understand the issues here well >> enough to proffer an opinion of my own just yet... but I'd like to >> hear what other people think. > > I'm certainly of the opinion that we want this or something similar. > > The big caveat kicking around in my head is if we want to have our own > set of defined policies or if we want to give flexibility to the > administrator to define their own policies. In particular, I'm > wondering about things like: > > CREATE POLICY namespace_limit ON pg_namespace TO company1 USING > (substring(nspname,1,8) = 'company1_'); > > Which is a bit different, as I understand it, from what Haribadu has > been proposing and quite a bit more complicated, as we'd then have to > make the internal lookups respect the policy (so things like CREATE > SCHEMA would have to check if you're allowed to actually create that > schema, which would be based on the policy...).
I feel we may needed both our own set of policies and also providing the user to create/alter/drop the catalog policies. This way we can support both simple and complex scenarios. With default policies an user can setup multi-tenancy easily. With the help of edit option, user can tune the policies according to their scenarios. The one problem with either approach as i am thinking, currently with our own set of policies, the objects entries that are present on the catalog tables are visible to the users, those are having any kind of privileges on those objects. In case if a user tries to create an object that is already present in the catalog relation will produce an error, but user cannot view that object because of permissions problem. To avoid such problem, administrator has to add policies such as "namespace_prefix" needs to be added to all catalog tables. Regards, Hari Babu Fujitsu Australia -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
