On Fri, Aug 21, 2026 at 4:49 PM Melanie Plageman <[email protected]> wrote: > On Fri, Aug 21, 2026 at 5:36 AM Zsolt Parragi <[email protected]> > 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
