Hi, At the moment we allow ALTER OPERATOR FAMILY to add/drop almost any part of the family, while ALTER OPERATOR CLASS allows changing only the name, owner and schema.
The ALTER OPERATOR FAMILY docs [1] explain that this is because the elements included in operator family are loose/optional, and not required for any specific index, and can be dropped at any time, while opclass defines stuff "required" by individual indexes ... and dropping any of it would require dropping the opclass, which requires dropping the indexes referencing it. I wonder if maybe we could relax this a bit, in some way ... The reason is a recent bug PostGIS bug [2], and how it got fixed. The gist of it is that PostgGIS defined a couple BRIN opclasses, those opclasses were always broken, but the parallel builds in PG17 made it trivial to hit it and cause a crash. Which could happen even before PG17, but it was much less likely (requires concurrent updates, but those tables are usually static). The thing is, the index was fine - even if it crashed, the index should not have been corrupted or anything. But fixing the bug requires changing the opclasses - adding a missing (required) MERGE procedure, and replacing a custom add_value proc with the built-in one. The latter could have been done by keeping the custom function and just calling the built-in variant, but there was no way to add the missing MERGE proc. At that point the only "supported" fix is to drop the opclass with all the indexes, and then recreate everything. But that's pretty painful, especially when you know the indexes are OK and the tables are massive (which is often the case for tables with GIS data, and that's also why people use BRIN, after all). Which is why PostGIS devs chose a different path - updating the catalogs to modify the opclass definition [3], using this script [4]. That's a bit ... terrifying. I assume the reason why we don't allow ALTER OPERATOR CLASS to change these fields is we're concerned people might break existing indexes / crash the server. But there's probably many "supported" ways leading to the same thing (I could change the C function backing the opclass), and if people instead opt to update catalogs directly, did it even protect against anything? In any case, I'd expect only superuser to be allowed to do this, just like for ALTER OPERATOR FAMILY. So why is this different? Or am I missing some fundamental reason why we don't want to allow ALTER OPERATOR CLASS to change some of the parts? regards [1] https://www.postgresql.org/docs/current/sql-alteropfamily.html [2] https://lists.osgeo.org/pipermail/postgis-devel/2025-January/030457.html [3] https://lists.osgeo.org/pipermail/postgis-devel/2025-January/030469.html [4] https://git.osgeo.org/gitea/postgis/postgis/src/branch/stable-3.5/postgis/postgis_after_upgrade.sql#L281 -- Tomas Vondra
