Why is FOR ORDER BY function getting called when the index is handling ordering?

Sorry to have to ask for help here, but no amount of stepping through code is giving me the answer.

I'm building an index access method which supports an ordering operator:

    CREATE OPERATOR pg_catalog.<<=>> (
        FUNCTION = rdb.rank_match,
        LEFTARG = record,
        RIGHTARG = rdb.RankSpec
    );

    CREATE OPERATOR CLASS rdb_ops DEFAULT FOR TYPE record USING rdb AS
        OPERATOR 1 pg_catalog.<===> (record, rdb.userqueryspec),
        OPERATOR 2 pg_catalog.<<=>> (record, rdb.rankspec) FOR ORDER BY pg_catalog.float_ops;

Here is the supporting code (in Rust):

    #[derive(Serialize, Deserialize, PostgresType, Debug)]
    pub struct RankSpec {
        pub fastrank: String,
        pub slowrank: String,
        pub candidates: i32,
    }

    #[pg_extern(
    sql = "CREATE FUNCTION rdb.rank_match(rec record, rankspec rdb.RankSpec) \
    RETURNS real IMMUTABLE STRICT PARALLEL SAFE LANGUAGE c \
    AS 'MODULE_PATHNAME', 'rank_match_wrapper';",
    requires = [RankSpec],
    no_guard
    )]
    fn rank_match(_fcinfo: pg_sys::FunctionCallInfo) -> f32 {
        // todo make this an error
        pgrx::log!("Error -- this ranking method can only be called when there is an RDB full-text search in the WHERE clause.");
        42.0
    }

    #[pg_extern(immutable, strict, parallel_safe)]
    fn rank(fastrank: String, slowrank: String, candidates: i32) -> RankSpec {
        RankSpec {
            fastrank,
            slowrank,
            candidates,
        }
    }

The index access method works fine. It successfully gets the keys and the orderbys in the amrescan() method, and it dutifully returns the appropriate scan.xs_heaptid in the amgettuple() method. It returns the tids in the proper order. It also sets:

scandesc.xs_recheck = false;
scandesc.xs_recheckorderby = false;

so there's no reason the system needs to know the actual float value returned by rank_match(), the ordering operator distance function. In any case, that value can only be calculated based on information in the index itself, and can't be calculated by rank_match().

Nevertheless, the system calls rank_match() after every call to amgettuple(), and I can't figure out why. I've stepped through the code, and it looks like it has something to do with ScanState.ps.ps.ps_ProjInfo, but I can't figure out where or why it's getting set.

Here's a sample query. I have not found a query that does *not* call rank_match():

SELECT *
FROM products
WHERE products <===> rdb.userquery('teddy')
ORDER BY products <<=>> rdb.rank();

I'd be grateful for any help or insights.


--