On Mon, Dec 4, 2023 at 4:23 PM Peter Eisentraut <pe...@eisentraut.org> wrote:
> > Looking at the code, I suspect these rules were just sort of > copy-and-pasted from the nearby rules for types and collations. The > latter are needed so that a table with inheritance children can present > a logically consistent view of the data. But compression and storage > are physical properties that are not logically visible, so every table > in an inheritance hierarchy can have their own setting. Incidentally I was looking at that code yesterday and had the same thoughts. > > I think the rules should be approximately like this (both for > compression and storage): > > - A newly created child inherits the settings from the parent. > - A newly created child can override the settings. > - Attaching a child changes nothing. Looks fine to me. > - When inheriting from multiple parents with different settings, an > explicit setting in the child is required. When no explicit setting for child is specified, it will throw an error as it does today. Right? -- Best Wishes, Ashutosh Bapat
