Operator classes/families with the same name about pg_validate_extupgrade HOT 8 CLOSED

Hi,

Thanks a lot! I also needed something to validate complex extension upgrades, so I'm happy it helps other people too.

I agree with you, the current behavior is to assume that an opfamily, identified by schema + opfamily name is unique, while it should only be unique for a given access method too, thus the invalid output you're getting. I will fix that as soon as I can.

To recreate a test, I think that you need to update (rename as you did in your extension) the row with the lowest ctid, so the next seq scan will return the rows in a different order.

from pg_validate_extupgrade.

I just pushed at fix at 0bbacb3, could you check to make sure it also fixes the problem for you?

FTR I was able to create a small reproducer, but I needed to use 3 operator families and not just 2.

from pg_validate_extupgrade.

Hi, @rjuju. That was fast, and it did fix the problem for me! 👍🏿 Thanks again for this excellent tool.

from pg_validate_extupgrade.

Great news, thanks a lot!

from pg_validate_extupgrade.

Errors have begun popping up again, no longer for opfamilies but instead for opclasses:

- mismatch found for Extension h3:
  - in opclasses:
    installed and upgraded both have 2 OpClass but some mismatch in them:
      - mismatch found for OpClass public.h3index_ops:
        - in opcmethod:
          - btree
          + hash

Is it possible that adding || ' USING ' || am.amname" is also required for opclass?

from pg_validate_extupgrade.

Good catch again, thanks a lot for the report!

Commit 8d23a3e should fix the issue.

from pg_validate_extupgrade.

Yup, that fixed it, thanks @rjuju!

from pg_validate_extupgrade.

Great, thanks for the confirmation!

from pg_validate_extupgrade.