On Sun, May 25, 2025 at 10:57 PM Peter Eisentraut <pe...@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              ~{:-)
p...@illuminatedcomputing.com


Reply via email to