> So let's get rid of that. Selecting (or in general, operating) on a > table with children only checks the privileges on that table, not the > children. Is there any use case where the current behavior is useful at > all?
In theory, someone out there may be using privs to restrict access to child tables. In practice, this would be unmanageable enough that I doubt anyone is doing it intentionally. Except ... I can imagine a multi-tenant setup where certain ROLEs only have permissions on some child relations, but not others. So we'd want to still enable a permissions check on a child when the child is called directly rather than through the parent. And we'd want to hammer this to death looking for ways it can be a security exploit. Like, could you make a table into the parent of an existing table you didn't have permissions on? > We could use a GUC variable to ease the transition, perhaps like > sql_inheritance = no | yes_without_privileges | yes no | without_privileges | yes Mind you, this is a boolean now, isn't it? --Josh Berkus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
