On Tue, Dec 13, 2022 at 01:06:48PM +0530, Bharath Rupireddy wrote: > A review comment in another thread [1] by Michael Paquier about the > usage of get_call_result_type() instead of explicit building of > TupleDesc made me think about using it more widely. Actually, the > get_call_result_type() looks at the function definitions to figure the > column names and build the required TupleDesc, usage of which avoids > duplication of the column names between pg_proc.dat/function > definitions and source code. Also, it saves a good number of LOC ~415 > [2] and the size of all the object files put together gets reduced by > ~4MB, which means, the postgres binary becomes leaner by ~4MB [3]. I'm > attaching a patch for these changes.
I have wanted to look at that when poking at the interface for materialized SRFs but lacked of steam back then. Even after this change, we still have coverage for CreateTemplateTupleDesc() and TupleDescInitEntry() through the GUCs/SHOW or even WAL sender, so the coverage does not worry me much. Backpatch conflicts may be a point of contention, but that's pretty much in the same spirit as SetSingleFuncCall()/InitMaterializedSRF(). All in that, +1 (still need to check in details what you have here, looks rather fine at quick glance). -- Michael
signature.asc
Description: PGP signature
