On 2020-Dec-09, tsunakawa.takay@fujitsu.com wrote:
> From: Alvaro Herrera <alvherre@alvh.no-ip.org>
> > But what happens when you create another partition after you change the
> > "loggedness" of the partitioned table?
>
> The new partition will have a property specified when the user creates
> it. That is, while the storage property of each storage unit
> (=partition) is basically independent, ALTER TABLE on a partitioned
> table is a convenient way to set the same property value to all its
> underlying storage units.
Well, that definition seems unfriendly to me. I prefer the stance that
if you change the value for the parent, then future partitions inherit
that value.
> I got an impression from the discussion that some form of consensus on
> the principle was made and you were trying to create a fix for REPLICA
> IDENTITY. Do you think the principle was unclear and we should state
> it first (partly to refresh people's memories)?
I think the principle was sound -- namely, that we should make all those
commands recurse by default, and for cases where it matters, the
parent's setting should determine the default for future children.
> I'm kind of for it, but I'm hesitant to create the fix for all ALTER
> actions, because it may take a lot of time and energy as you were
> afraid. Can we define the principle, and then create individual fixes
> independently based on that principle?
That seems acceptable to me, as long as we get all changes in the same
release. What we don't want (according to my reading of that
discussion) is to change the semantics of a few subcommands in one
release, and the semantics of a few other subcommands in another
release.