Hi, Pavel!
On Tue, Jun 30, 2026 at 2:25 PM Pavel Borisov <pashkin.elfe@gmail.com> wrote:
> On Tue, 30 Jun 2026 at 15:07, Alexander Korotkov <aekorotkov@gmail.com> wrote:
> > On Fri, Jun 26, 2026 at 10:50 PM Alexander Korotkov
> > <aekorotkov@gmail.com> wrote:
> > > On Fri, Jun 26, 2026 at 6:20 PM Dmitry Koval <d.koval@postgrespro.ru> 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
