Re: New "single-call SRF" APIs are very confusingly named
От | Andres Freund |
---|---|
Тема | Re: New "single-call SRF" APIs are very confusingly named |
Дата | |
Msg-id | 20221014013426.2cgcnb72uyolu3ax@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: New "single-call SRF" APIs are very confusingly named (Michael Paquier <michael@paquier.xyz>) |
Список | pgsql-hackers |
Hi, On 2022-10-14 10:28:34 +0900, Michael Paquier wrote: > On Thu, Oct 13, 2022 at 12:48:20PM -0700, Andres Freund wrote: > > Maybe something like InitMaterializedSRF() w/ > > MAT_SRF_(USE_EXPECTED_DESC|BLESS) > > Or just SetMaterializedFuncCall()? I think starting any function that's not a setter with Set* is very likely to be misunderstood (SetReturning* is clearer, but long). This just reads like you're setting the materialized function call on something. > Do we always have to mention the SRF part of it once we tell about the > materialization part? Yes. The SRF is the important part. > The latter sort implies the former once a function returns multiple tuples. There's lot of other other things that can be materialized. > I don't mind doing some renaming of all that even post-release, though > comes the question of keeping some compabitility macros for > compilation in case one uses these routines? Agreed that we'd need compat. I think it'd need to be compatibility function, not just renaming via macro, so we keep ABI compatibility. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: