Simon, >> We could use a GUC variable to ease the transition, perhaps like >> sql_inheritance = no | yes_without_privileges | yes > > The original way of doing things was quite useful if you wanted some > people to be able to see history and others just see recent data. I > don't think many people are aware of or take advantage of that, so your > proposal does simplify things for many people. > > Would it not be better to offer this as a table-level option, with > default of check-permission-on-parent-only?
No, I don't think so. The original way *wasn't* actually useful if you wanted to differentiate between which partitions people could see. Example: You partition the sales table geographically. You want salespeople to only be able to see their own geo, but management to be able to see all: role staff manager inherits staff sales_USA inherits staff sales_CAN inherits staff sales_EUR inherits staff master table sales grant SELECT: staff sales_CAN inherits sales grant SELECT: manager, sales_CAN sales_USA inherits sales grant SELECT: manager, sales_USA sales_EUR inherits sales grant SELECT: manager, sales_EUR So, then a USA-role salesperson does "SELECT sum(gross) FROM sales;". What happens? A permissions error. *Not* the desired seeing only the USA data. In order for a user which privs on only some partitions to see the data in those partitions, that user needs to query the partitions directly. The proposed patch would not change that. The only thing it would change is that DBAs would need to be careful to be restrictive about permissions granted on the master table. --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
