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