Обсуждение: Pre-installed index access methods cannot be manually installed.

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

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

I just realised that the failure of the specific mentioned test case
was unrelated to the issue at hand, as it correctly shows that you
can't use int8-opclasses for int4 columns.

The attached fixes that test case by creating a table with a bigint
column instead, so that the test correctly, but unexpectedly, outputs
"ERROR:  unexpected non-btree AM: NNNNN".

- Matthias

Matthias van de Meent <boekewurm+postgres@gmail.com> 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 OID of the
> supplied relation's access method, which will not match the expected
> value when manually installed.

This seems like a straw argument, considering that there would be
dozens of other problems in the way of removing or replacing any
built-in index AMs.

> Is this expected? Would we accept patches that remove or reduce the
> impact of these artificial limitations?

Seems like a significant waste of effort to me.

            regards, tom lane