Re: MERGE/SPLIT PARTITIONS issues/questions

On Fri, Aug 21, 2026 at 4:49 PM Melanie Plageman
<melanieplageman(at)gmail(dot)com> wrote:
> On Fri, Aug 21, 2026 at 5:36 AM Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> wrote:
> >
> > I don't think 0005 is correct. Similar to the other changes, the
> > intention should be "do not change the table access method in an
> > invisible way to the user".
> >
> > The current patch still drops explicit table AMs for a partition
> > (CREATE TABLE tp PARTITION OF ... USING otheram) in favor of the
> > parent AM or even the current session default AM.
> > Merge of partitions with different AMs still succeed.
> >
> > I have to agree with Daniel's reasoning earlier:
> >
> > > Apart from the obviously dangerous ones like RLS and ACL, silently dropping the
> > > table AM may induce side-effects which are hard for us to even reason about
> > > since they are external to the core code.
> >
> > As an example, we have pg_tde which provides an encrypted version of
> > the heap AM. Silently changing the table AM in our case means that we
> > remove encryption from the data without notifying the user about it.
> > We can detect such commands in an event trigger and disable them to
> > prevent accidents, but I don't think this should be left to extension
> > authors.
> >
> > > As I mentioned in [1], I think this is the way to save this feature
> > > for pg19. I think it's too late to introduce new (and debatable)
> > > functionality.
> >
> > My opinion is that things like silently dropping triggers or default
> > values or constraints can result in similar dangerous accidents.
>
> I thought we were going to disallow using merge/split on child
> partitions with any differences from the parent partition at all. That
> way copying everything from the parent would work fine. That seems
> like the way forward to me at this point.

+1, that was the way forward I was going to propose. I'm going to
post the patch later today.

------
Regards,
Alexander Korotkov
Supabase