On Fri, Feb 23, 2024 at 6:05 PM Ashutosh Bapat <ashutosh.bapat....@gmail.com> wrote: > > On Tue, Feb 20, 2024 at 3:51 PM Peter Eisentraut <pe...@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