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
signature.asc
Description: PGP signature
