Hi, Alexander! 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."
Regards, Pavel Borisov Supabase
