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

On Sun, Oct 16, 2022 at 03:09:14PM -0700, Andres Freund wrote:
> On 2022-10-15 11:41:08 +0900, Michael Paquier wrote:
>> -/* 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.

That's just assign_record_type_typmod(), which would make sure to fill
the cache for a RECORD tupdesc. How about "fill the cache with the
information of the tuple descriptor type, for a transient RECORD
datatype"? If you have a better, somewhat less confusing, idea, I am
open to suggestions.

>> @@ -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?

Yeah, that's fine as well.
--
Michael