From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: table inheritance versus column compression and storage settings |
Date: | 2024-03-21 09:49:47 |
Message-ID: | 0f3d5151-009d-452b-8652-ed6f1031f8c8@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 07.03.24 17:54, Ashutosh Bapat wrote:
> The pg_dump problems arise because we throw an error when parents have
> conflicting compression and storage properties. The patch that got
> reverted, changed this slightly by allowing a child to override parent's
> properties even when they conflict. It still threw an error when child
> didn't override and parents conflicted. I guess, MergeAttributes()
> raises error when it encounters parents with conflicting properties
> because it can not decide which of the conflicting properties the child
> should inherit. Instead it could just set the DEFAULT properties when
> parent properties conflict but child doesn't override. Thus when
> compression conflicts, child's compression would be set to default and
> when storage conflicts it will be set to the type's default storage.
> Child's properties when specified explicitly would override always. This
> will solve all the pg_dump bugs we saw with the reverted patch and also
> existing bug I reported earlier.
>
> This change would break backward compatibility but I don't think anybody
> would rely on error being thrown when parent properties conflict.
>
> What do you think?
At this point in the development cycle, I would rather not undertake
such changes. We have already discovered with the previous attempt that
there are unexpected pitfalls and lacking test coverage. Also, there
isn't even a patch yet. I suggest we drop this for now, or reconsider
it for PG18, as you wish.
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2024-03-21 09:50:01 | Re: Introduce XID age and inactive timeout based replication slot invalidation |
Previous Message | Shlok Kyal | 2024-03-21 09:49:16 | Re: speed up a logical replica setup |