On Thu, Apr 16, 2026 at 9:03 PM Matheus Alcantara
<matheusssilv97@gmail.com> wrote:
>
> On Tue Apr 14, 2026 at 6:05 AM -03, Dmitry Koval wrote:
> > Hi Matheus!
> >
> > Thank you for patch.
> > I agree that dependency should be automatically added for SPLIT
> > PARTITION. But I'm not sure about MERGE PARTITION ...
> > Might be it would be more correct to automatically add a dependency only
> > if all merged partitions have it?
>
> Hi,
>
> Thank you for taking a look on this!
>
> I agree with your suggestion. The attached patch implements the
> intersection behavior for MERGE PARTITIONS: extension dependencies are
> only preserved on the merged partition's index if all source partition
> indexes have that dependency.
>
> For example:
> MERGE(idx1(ext_a, ext_b), idx2(ext_a)) -> idx3(ext_a) -- only ext_a is common
> MERGE(idx1(ext_a), idx2()) -> idx3() -- no common deps
This is not obvious for me. I would rather trigger an error if there
are different dependencies on merging partitions.
> For SPLIT PARTITION, the behavior remains the same since there's only
> one source partition, all its extension dependencies are copied to the
> new partition indexes.
>
> While working on this patch, I noticed what might be a separate bug (or
> perhaps intentional behavior that I don't understand): extension
> dependencies on parent partitioned indexes don't seem to prevent DROP
> EXTENSION, but dependencies on child partition indexes do. See this
> example:
>
> CREATE EXTENSION IF NOT EXISTS btree_gist;
>
> CREATE TABLE t (i int) PARTITION BY RANGE (i);
> CREATE TABLE t_1 PARTITION OF t FOR VALUES FROM (1) TO (2);
> CREATE INDEX t_idx ON t USING gist (i);
>
> -- Add dependency on the PARENT partitioned index
> ALTER INDEX t_idx DEPENDS ON EXTENSION btree_gist;
>
> -- This succeeds (I expected it to fail):
> DROP EXTENSION btree_gist;
>
> But if I add the dependency on the child partition index instead:
>
> ALTER INDEX t_1_i_idx DEPENDS ON EXTENSION btree_gist;
>
> DROP EXTENSION btree_gist;
> ERROR: cannot drop extension btree_gist because other objects depend on it
> DETAIL: index t_idx depends on operator class gist_int4_ops for access method gist
>
> Is this expected behavior, or a separate bug? I would have expected the
> dependency on the parent index to also prevent the DROP.
Note that if you don't create explicit dependency then you would get
an error. When you create an explicit dependency index => extension,
it's a different kind than the automatic one. It causes index to be
dropped on extension drop (as documented). Thus, if you create
dependency child_index => extension, then child_index gets dropped,
but parent_index automatic dependency still prevents deletion. But if
you create dependency parent_index => extension then dropping of
extension trigger dropping of the parent_index, in turn that dropping
child_index. So, everything is dropped, no errors. I don't think
there is a bug.
------
Regards,
Alexander Korotkov
Supabase
