Re: Index AM API cleanup

On 04.02.25 14:31, Peter Eisentraut wrote:
> On 03.02.25 12:08, Peter Eisentraut wrote:
>> Yeah, actually this turned out to be unnecessary, because you can
>> easily obtain the AM OID from the passed-in opclass ID.  So I have
>> fixed it that way.  I have committed this whole patch set now with the
>> mentioned adjustments.  I'll post a rebased version of the main patch
>> set soon.
>
> I picked off two more patches from the full patch series that can be
> dealt with easily.  These are
>
> - Support non-btree indexes for foreign keys
> - Allow non-btree speculative insertion indexes
>
> (v19-0012 and v19-0013)
>
> The version of these patches that were posted in the v19 bundle replaced
> the hardcoded comparison with BTREE_AM_OID by a check against
> (indirectly) amcanunique.  But I think that is not necessary, because at
> that point we already know that we are dealing with a unique index.  The
> reason for the check against BTREE_AM_OID was that we didn't have a way
> to get the right strategy number for other index methods.  But now we
> have, so we can use the strategy translation functions and we don't need
> to check for btree-ness anymore.
>
> See attached patches.

I have committed these.

Here is another small issue. In the v19.2 patches, I had changed the
argument of the gist strategy translation function from opclass to
opfamily+opcintype. This worked well with the existing uses, but when
rebasing the rest of the main patch set, it seems that the correct value
of "opcintype" is not always clear or readily available. And if you
think about it, we don't need that type, because the strategy mapping
function is surely the same for all types supported by an opfamily. So
we could simplify that by registering the gist stratnum support function
in a way that you can look it up without having to worry about the type.
Apparently, you can't register it with just zero in
amproclefttype/amprocrighttype, that confuses some DDL commands. But I
figure we could put the pseudotype "any" in there, which is moderately
intuitive. And then we can drop the opcintype from all the APIs, which
simplifies things.

See attached patches. Thoughts?