From: Alvaro Herrera <alvhe...@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 ALTER TABLE mytable SET (fillfactor = 70) and then CREATE TABLE mytable_p1 PARTITION OF mytable, I find it nice that the fillfactor os mytable_p1 is also 70 (but I won't complain if it isn't, since I can run ALTER TABLE SET on the parent table again.) 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 default for 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 understood consistency 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-patching sometimes, 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
