Re: table inheritance versus column compression and storage settings

On Fri, Feb 23, 2024 at 6:05 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> On Tue, Feb 20, 2024 at 3:51 PM Peter Eisentraut <peter@eisentraut.org> wrote:
> >
> > I have reverted the patch for now (and re-opened the commitfest entry).
> > We should continue to work on this and see if we can at least try to get
> > the pg_dump test coverage suitable.
> >
>
> I have started a separate thread for dump/restore test. [1].
>
> Using that test, I found an existing bug:
> Consider
> CREATE TABLE cminh6 (f1 TEXT);
> ALTER TABLE cminh6 INHERIT cmparent1;
> f1 remains without compression even after inherit per the current code.
> But pg_dump dumps it out as
> CREATE TABLE cminh6 (f1 TEXT) INHERIT(cmparent1)
> Because of this after restoring cminh6::f1 inherits compression of
> cmparent1. So before dump cminh6::f1 has no compression and after
> restore it has compression.
>
> I am not sure how to fix this. We want inheritance children to have
> their on compression. So ALTER TABLE ... INHERIT ... no passing a
> compression onto child is fine. CREATE TABLE .... INHERIT ... passing
> compression onto the child being created also looks fine since that's
> what we do with other attributes. Only solution I see is to introduce
> "none" as a special compression method to indicate "no compression"
> and store that instead of NULL in attcompression column. That looks
> ugly.

Specifying DEFAULT as COMPRESSION method instead of inventing "none"
works. We should do it only for INHERITed tables.

>
> Similar is the case with storage.
>

Similar to compression, for inherited tables we have to output STORAGE
clause even if it's default.

-- 
Best Wishes,
Ashutosh Bapat