From: Kyotaro Horiguchi <horikyota....@gmail.com> > "CREATE TABLE" is not "CREATE LOGGED TABLE". We can assume that as > "CREATE <default logged-ness> TABLE", where the default logged-ness > varies according to context. Or it might have been so since the beginning. > Currently we don't have the syntax "CREATE LOGGED TABLE", but we can add > that syntax.
Yes, I thought of that possibility after a while too. But I felt a bit(?) hesitant to do it considering back-patching. Also, the idea requires ALTER TABLE ATTACH PARTITION will have to modify the logged-ness property of the target partition and its subpartitions with that of the parent partitioned table. However, your idea is one candidate worth pursuing, including whether or not to back-patch what. > We pursue relasing all fixes at once but we might release all fixes other > than > some items that cannot be fixed for some technical reasons at the time, like > REPLICA IDENITTY. > > I'm not sure how long we will wait for the time of release, though. Anyway, we have to define the ideal behavior for each ALTER action based on some comprehensible principle. Yeah... this may become a long, tiring journey. (I anticipate some difficulty and compromise in reaching agreement, as was seen in the past discussion for the fix for ALTER TABLE REPLICA IDENTITY. Scary) FWIW, I wonder why Postgres decided to allow different logical structure of tables such as DEFAULT values and constraints between the parent partitioned table and a child partition. That extra flexibility might stand in the way to consensus. I think it'd be easy to understand that partitions are simply physically independent containers that have identical logical structure. Regards Takayuki Tsunakawa
