Matthias van de Meent writes:
> 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 O
> 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
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 limitati
