Nonrecursive ALTER TABLE ADD/RENAME COLUMN is wrong

Fernando Nasser of Red Hat reminded me that it really makes no sense
for ALTER TABLE ADD COLUMN and ALTER TABLE RENAME COLUMN to behave
non-recursively --- that is, they should *always* affect inheritance
children of the named table, never just the named table itself.

After a non-recursive ADD/RENAME, you'd have a situation wherein
"SELECT * FROM foo" would fail, because there'd be no corresponding
columns in the child table(s).  This seems clearly bogus to me.
(On the other hand, non-recursive DROP COLUMN, if we had one, would
be okay ... the orphaned child columns would effectively become
non-inherited added columns.  Similarly, non-recursive alterations of
defaults, constraints, etc seem reasonable.)

As of 7.2 we do accept "ALTER TABLE ONLY foo" forms of these commands,
but I think that's a mistake arising from thoughtless cut-and-paste
from the other forms of ALTER.  I believe it is better to give an error
if such a command is given.  Any objections?

Also, in the case where neither "ONLY foo" nor "foo*" is written, the
behavior currently depends on the SQL_INHERITANCE variable.  There's
no problem when SQL_INHERITANCE has its default value of TRUE, but what
if it is set to FALSE?  Seems to me we have two plausible choices:
* Give an error, same as if "ONLY foo" had been written.
* Assume the user really wants recursion, and do it anyway.

The second seems more user-friendly but also seems to violate the
principle of least surprise.  Anyone have an opinion about what to do?
        regards, tom lane