On Sun, May 25, 2025 at 10:57 PM Peter Eisentraut <peter@eisentraut.org> wrote:
> Here we added a gist support function that we internally refer to by the
> symbol GIST_STRATNUM_PROC. This translated from "well-known" strategy
> numbers to opfamily-specific strategy numbers. However, we later
> changed this to fit into index-AM-level compare type mapping, so this
> function actually now maps from compare type to opfamily-specific
> strategy numbers. So I'm wondering if this name is still good.
>
> Moreover, the index AM level also supports the opposite, a function to
> map from strategy number to compare type. This is currently not
> supported in gist, but one might wonder what this function is supposed
> to be called when it is added.
>
> So I went through and updated the naming of the gist-level functionality
> to be more in line with the index-AM-level functionality; see attached
> patch. I think this makes sense because these are essentially the same
> thing on different levels. What do you think? (This would be for PG18.)
I agree this rename makes sense.
Here do we want to say "respective operator class" instead of
"respective operator family"? Or "operator class/family"? Technically
btree_gist attaches it to the whole opfamily, but that's only because
there is no appropriate ALTER OPERATOR CLASS functionality:
@@ -1188,12 +1188,23 @@ <title>Extensibility</title>
non-<literal>WITHOUT OVERLAPS</literal> part(s) of an index constraint.
</para>
+ <para>
+ This support function corresponds to the index access method callback
+ function <structfield>amtranslatecmptype</structfield> (see <xref
+ linkend="index-functions"/>). The
+ <structfield>amtranslatecmptype</structfield> callback function for
+ GiST indexes merely calls down to the
+ <function>translate_cmptype</function> support function of the
+ respective operator family, since the GiST index access method has no
+ fixed strategy numbers itself.
+ </para>
+
<para>
The <acronym>SQL</acronym> declaration of the function must look like
this:
Yours,
--
Paul ~{:-)
pj@illuminatedcomputing.com