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