Re: MERGE PARTITIONS and DEPENDS ON EXTENSION.

On Wed Apr 22, 2026 at 7:59 AM -03, Kirill Reshke wrote:
> On Wed, 22 Apr 2026 at 15:58, Matheus Alcantara
> <matheusssilv97(at)gmail(dot)com> wrote:
>>
>> On Wed Apr 22, 2026 at 7:48 AM -03, Kirill Reshke wrote:
>> >> +-- An index created directly on a partition has no parent in the partitioned
>> >> +-- index tree; merge must ignore such indexes (they disappear with the old
>> >> +-- partition).
>> >> +CREATE INDEX part_extdep_3_extra_idx ON part_extdep_3(x);
>> >> +ALTER TABLE part_extdep MERGE PARTITIONS (part_extdep_merged, part_extdep_3)
>> >> + INTO part_extdep_merged2;
>> >> +SELECT relname FROM pg_class
>> >> +WHERE relname LIKE 'part_extdep_merged2%idx' ORDER BY relname;
>> >
>> > Looks like this test is also redundant? This does not test new DEPENDS ON logic.
>> >
>>
>> I think that this test is useful to ensure that we correctly skip such
>> indexes created directly on a specific partition. Perhaps we can include
>> an ALTER INDEX ... DEPENDS ON for this specific index to make it more
>> consistent with the other tests?
>
> This test is maybe useful, but this is unrelated to what this thread &
> fix is about, for my taste.
>

On collectPartitionIndexExtDeps() we have:
if (!get_rel_relispartition(indexOid))
continue;

parentIndexOid = get_partition_parent(indexOid, true);
if (!OidIsValid(parentIndexOid))
continue;

I think that this test ensure that get_rel_relispartition() check is
called, otherwise we will call get_partition_parent() with an index that
don't have parent which will fail with an elog(ERROR).

It can be unrelated but I think that it ensure correctness for this fix,
or I'm missing something here?

--
Matheus Alcantara
EDB: https://www.enterprisedb.com