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".
