Re: New "single-call SRF" APIs are very confusingly named

Hi,

On 2022-10-15 11:41:08 +0900, Michael Paquier wrote:
> Attached is a patch for HEAD and REL_15_STABLE to switch this stuff with new
> names, with what's needed for ABI compatibility.  My plan would be to keep
> the compatibility parts only in 15, and drop them from HEAD.  -- Michael

Looks reasonable to me. Thanks for working on this.


> -/* flag bits for SetSingleFuncCall() */
> -#define SRF_SINGLE_USE_EXPECTED    0x01    /* use expectedDesc as tupdesc */
> -#define SRF_SINGLE_BLESS        0x02    /* validate tuple for SRF */
> +/* flag bits for InitMaterializedSRF() */
> +#define MAT_SRF_USE_EXPECTED_DESC    0x01    /* use expectedDesc as tupdesc */
> +#define MAT_SRF_BLESS                0x02    /* complete tuple descriptor, for
> +                                             * a transient RECORD datatype */

I don't really know what "complete tuple descriptor" means. BlessTupleDesc()
does say "make a completed tuple descriptor useful for SRFs" - but I don't
think that means that Bless* makes them complete, but that they *have* to be
complete to be blessed.


> @@ -2164,8 +2164,8 @@ elements_worker_jsonb(FunctionCallInfo fcinfo, const char *funcname,
>  
>      rsi = (ReturnSetInfo *) fcinfo->resultinfo;
>  
> -    SetSingleFuncCall(fcinfo,
> -                      SRF_SINGLE_USE_EXPECTED | SRF_SINGLE_BLESS);
> +    InitMaterializedSRF(fcinfo,
> +                      MAT_SRF_USE_EXPECTED_DESC | MAT_SRF_BLESS);

Already was the case, so maybe not worth mucking with: Why the newline here,
but not in other cases?

Greetings,

Andres Freund