On Mon, Dec 4, 2023 at 4:23 PM Peter Eisentraut <peter@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