RE: [bug fix] ALTER TABLE SET LOGGED/UNLOGGED on a partitioned table does nothing silently

From: Alvaro Herrera <alvherre@alvh.no-ip.org>
> 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.

That would be right when the storage property is an optional specification such as fillfactor.  For example, when I run
ALTERTABLE mytable SET (fillfactor = 70) and then CREATE TABLE mytable_p1 PARTITION OF mytable, I find it nice that the
fillfactoros mytable_p1 is also 70 (but I won't complain if it isn't, since I can run ALTER TABLE SET on the parent
tableagain.) 

OTOH, CREATE TABLE and CREATE UNLOGGED TABLE is an explicit request to create a logged and unlogged relation
respectively. I feel it a strange? if CREATE TABLE mytable_p1 PARTITION OF mytable creates an unlogged partition. 


> > 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.

Yeah, recurse by default sounded nice.  But I didn't find a consensus related to "parent's setting should determine the
defaultfor future children."  Could you point me there? 


> > 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.

All fixes at one release seems constricting to me...  Reading from the following quote in the past discussion, I
understoodconsistency is a must and simultaneous release is an ideal.  So, I think we can release individual fixes
separately. I don't think it won't worsen the situation for users at least. 

"try to make them all work the same, ideally in one release, rather than changing them at different times,
back-patchingsometimes, and having no consistency in the details. 

BTW, do you think you can continue to work on your REPLICA IDENTITY patch soon?


Regards
Takayuki Tsunakawa