Hi, Pavel! On Tue, Jun 30, 2026 at 2:25 PM Pavel Borisov <[email protected]> wrote: > On Tue, 30 Jun 2026 at 15:07, Alexander Korotkov <[email protected]> wrote: > > On Fri, Jun 26, 2026 at 10:50 PM Alexander Korotkov > > <[email protected]> wrote: > > > On Fri, Jun 26, 2026 at 6:20 PM Dmitry Koval <[email protected]> > > > wrote: > > > > If we exclude case with DEFAULT partition, MERGE PARTITIONS command was > > > > intended to be used when an incorrect table partitioning was chosen. > > > > For example, a table was initially partitioned by month, but later we > > > > needed to change table partitioning by quarter. In this case, MERGE > > > > PARTITIONS command should merge several adjacent partitions into one. > > > > Current checks are made for this case. > > > > > > > > >- If there's *no* default partition, then I think the check should be > > > > >relaxed; it's sufficient to verify that the bounds of the merged > > > > >partition do not overlap with any partition which is not being merged; > > > > > > > > It's probably possible to do this. But in this case, the command will > > > > not exactly be "MERGE PARTITIONS" ("MERGE PARTITIONS & EXPAND"?). > > > > > > +1, > > > We can implement a support for this for 20. For 19, I propose to > > > state the restriction more explicit in the docs. See the attached > > > patch. > > > > I'm going to push the docs patch if no objections. > I looked at the doc patch. IMO "in order to be merged" is redundant. > I'd propose following: > "For range-partitioned tables, the ranges of merged partitions must be > adjacent. This applies even if the partitioned table has no default > partition."
I've included your suggestion. Pushed and and backpatched to 19. ------ Regards, Alexander Korotkov Supabase
