SFRM_Materialize_Preferred permite- lhe escrever uma função que aceite uma dica do chamador que pode aceitar Materializeou ValuePerCallmode da documentação no README

Os chamadores que podem suportar ambos ValuePerCalle o Materializemodo definirão SFRM_Materialize_Preferred, ou não, dependendo do modo que preferirem.

Isso está documentado como dica -- uma extensão para SFRM_Materialize-- na fonte,

SFRM_Materialize_Randome SFRM_Materialize_Preferredsão sinalizadores auxiliares sobre o SFRM_Materializemodo, em vez de modos separados.

Você também pode ver que isso é usado no código do PostgreSQL Function Manager para SQLfmgr_sql

lazyEvalOK = !(rsi->allowedModes & SFRM_Materialize_Preferred);

Minha própria demonstração

Eu criei minha própria demonstração muito simplificada SFRM_Materialize_Preferredpara fins de benchmarking. Você pode ver isso no meu repositório para o meu arquivopg-srf-repeat . Basicamente, o modelo se resume a isso,

Datum myfunc(PG_FUNCTION_ARGS);
PG_FUNCTION_INFO_V1(myfunc);

typedef struct
{
  ; your function state only used in value-per-call mode
} myfunc_fctx;

Datum
myfunc(PG_FUNCTION_ARGS)
{
  
    ; get variables
    
    if (SRF_IS_FIRSTCALL())
    {
        ReturnSetInfo   *rsinfo       = (ReturnSetInfo *) fcinfo->resultinfo;

        // If we prefer materialize, get it done
        if ( rsinfo->allowedModes & SFRM_Materialize_Preferred ) {

            MemoryContext   per_query_ctx = rsinfo->econtext->ecxt_per_query_memory;
            MemoryContext   oldcontext    = MemoryContextSwitchTo(per_query_ctx);

            Tuplestorestate *tupstore     = tuplestore_begin_heap(false, false, work_mem);
            rsinfo->setResult             = tupstore;
            rsinfo->returnMode            = SFRM_Materialize;
    
            TupleDesc   tupdesc = rsinfo->expectedDesc;

            Datum values[1]             = { ;stuff };
            bool  nulls[sizeof(values)] = {0}; # no nulls

            while ( times-- ) {
                tuplestore_putvalues(tupstore, tupdesc, values, nulls);
            }

            tuplestore_donestoring(tupstore);
            MemoryContextSwitchTo(oldcontext);
    
            PG_RETURN_NULL();
        }

        // Initialize for multicall
        else {
            FuncCallContext *funcctx = SRF_FIRSTCALL_INIT();
            MemoryContext oldcontext = MemoryContextSwitchTo(funcctx->multi_call_memory_ctx);
            myfunc_fctx *fctx = (myfunc_fctx *) palloc(sizeof(myfunc_fctx));

            # set myfunc_fctx
            funcctx->user_fctx = fctx;
            MemoryContextSwitchTo(oldcontext);
        }

    }
    
    FuncCallContext *funcctx  = SRF_PERCALL_SETUP();
    myfunc_fctx *fctx         = funcctx->user_fctx;

    # Call this
    SRF_RETURN_NEXT(funcctx, fctx->object);
    # Or this,
    SRF_RETURN_DONE(funcctx);

}

Isso geralmente parece executar o mais rápido de Materializeou ValuePerCalle a sobrecarga da implementação é menor (em comparação com uma implementação pura).

Em Pg-Python

Estou mantendo isso aqui por causa da escassez geral de informações pertinentes. Eu determinei que este SRF_SHOULD_MATERIALIZEcaso de macro é realmente muito bobo (eu abri um problema nele) ; o problema com a SRF_SHOULD_MATERIALIZEmacro é SFRM_Materializee SFRM_ValuePerCallsempre é verdade , então essencialmente é apenas uma versão mais lenta de SFRM_Materialize_Preferred**

Ele também parece ser usado no pg-pythonprojeto que permite acessar o Python 3 a partir do PostgreSQL Functions , mas não há casos de uso em todo o GitHub . A pg-pythonmacro para SRF_SHOULD_MATERIALIZEé a seguinte (veja a nota acima)

#define SRF_SHOULD_MATERIALIZE(FCINFO) (
  (
    ((ReturnSetInfo *) FCINFO->resultinfo)->allowedModes & SFRM_Materialize
  )
  && (
    !(
      ((ReturnSetInfo *) FCINFO->resultinfo)->allowedModes & SFRM_ValuePerCall
    )
    || ((
      ((ReturnSetInfo *) FCINFO->resultinfo)->allowedModes & SFRM_Materialize_Preferred
    ))
  )
)

Você pode ver a SRF_SHOULD_MATERIALIZEmacro usada uma vez no site da chamada