From: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: table inheritance versus column compression and storage settings |
Date: | 2024-03-21 11:16:29 |
Message-ID: | CAExHW5sbOdeCy0y_YgeVwZC7x_HZao_Pu67NsQnTP1Wr8PkkAQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Mar 21, 2024 at 3:19 PM Peter Eisentraut <peter(at)eisentraut(dot)org>
wrote:
> 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.
>
>
I am fine with this. Should I mark the CF entry as RWF?
--
Best Wishes,
Ashutosh Bapat
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Guo | 2024-03-21 11:20:30 | Re: Oversight in reparameterize_path_by_child leading to executor crash |
Previous Message | Dave Cramer | 2024-03-21 11:11:23 | Re: Trying to build x86 version on windows using meson |