From: Michael Paquier <mich...@paquier.xyz> > On Wed, Dec 09, 2020 at 09:52:17AM -0300, Alvaro Herrera wrote: > > 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's indeed more interesting from the user perspective. So +1 from me.
As I mentioned as below, some properties apply to that, and some don't. -------------------------------------------------- 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. -------------------------------------------------- Anyway, I think I'll group ALTER TABLE/INDEX altering actions based on some common factors and suggest what would be a desirable behavior, asking for opinions. I'd like to explore the consensus on the basic policy for fixes. Then, I hope we will be able to work on fixes for each ALTER action in patches that can be released separately. I'd like to regist requiring all fixes to be arranged at once, since that may become a high bar for those who volunteer to fix some of the actions. (Even a committer Alvaro-san struggled to fix one action, ALTER TABLE REPLICA IDENTITY.) Regards Takayuki Tsunakawa
