Re: propagating replica identity to partitions

> Fair enough.  I don't think it's entirely useful to think about this
> in terms of which operations do and don't recurse; the question in my
> mind is WHY some things recurse and other things don't, and what will
> be easiest for users to understand.

I think the reason tablespace was made not to recurse was to avoid
acquiring access exclusive lock on too many tables at once, but I'm not
sure.  This is very old behavior.

> Obviously any property where the
> parents and children have to match, like adding a column or changing a
> data type, has to always recurse; nothing else is sensible.  For
> others, it seems we have a choice.  It's unclear to me why we'd choose
> to make REPLICA IDENTITY recurse by default and, say, OWNER not
> recurse.

Ah.  I did argue that OWNER should recurse:
https://postgr.es/m/20171017163203.uw7hmlqonidlfeqj@alvherre.pgsql
but it was too late then to change it for pg10.  We can change it now,
surely.

> In both cases, the default assumption is presumably that the
> whole partitioning hierarchy should match, but in a particular case a
> user could want to do something else.  Consequently, I don't
> understand why a user would want one of those operations to descend to
> children by default and the other not.

I agree that OWNER TO should recurse for partitioned tables. 

I'm -0 on
changing it for legacy inheritance, but if the majority is to change it
for both, let's do that.