Privileges and inheritance

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?