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