Re: MERGE/SPLIT PARTITIONS issues/questions

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.

- Melanie