Hi, I noticed that in many places we check or assert the OIDs of our built-in AMs. E.g. in planning, we will only do row compares in indexes that have BTREE_AM_OID, and we can only sort tuples for btamhandler -based index ams if their oid is the BTREE_AM_OID. That seems like an artificial limitation to me.
Although it makes sense to ensure that we don't accidentally call such functions from the 'wrong location', it does mean that a user cannot manually install the preinstalled access methods and get a working index AM, because the internal code is checking the OID of the supplied relation's access method, which will not match the expected value when manually installed. Is this expected? Would we accept patches that remove or reduce the impact of these artificial limitations? Kind regards, Matthias van de Meent PS. I noticed this when checking the sortsupport code for some active patches, and after playing around a bit while trying to run PG extensions that are not system-registered. The attached test case fails, where I'd expect it to succeed, or at least I expected it not to fail at "This AM's OID has an unexpected value".
scratch_33.sql
Description: Binary data
