From: Peter Eisentraut on 3 Oct 2009 02:45 I would like to propose a change in the way privilege checking is done with inheritance hierarchies. Currently, selecting from a table that has children requires explicit privileges on all the children. This is inconsistent with all other commands, which treat children as implicitly part of the parent table. (Arguably, it exposes an implementation detail, since you could just as well implement inheritance by keeping all the children's data for the inherited columns in the parent's heap.) As inheritance has now found new popularity as a partitioning mechanism, this exacerbates the annoyance because you have to copy the privilege sets to possibly dozens or hundreds of subtables in cumbersome ways for really no good reason. If you use inheritance for data modeling (the original purpose), you face another problem. Either you grant table privileges on all the child tables, thus giving users access to more information than they were supposed to have, or you grant column privileges on only those columns that were inherited, being careful to keep that set updated whenever table definitions are altered. (Before 8.4 you couldn't even do that.) It's messy. 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? (What I gather from history and the code, I think it was just forgotten to change this when we switched away from the table* syntax way back when.) FWIW, changing this behavior would also be more SQL-conforming. We could use a GUC variable to ease the transition, perhaps like sql_inheritance = no | yes_without_privileges | yes Comments? -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
|
Pages: 1 Prev: LIMIT 1 == EXISTS optimization? Next: Could regexp_matches be immutable? |