On Tue, Dec 20, 2022 at 1:41 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Michael Paquier <mich...@paquier.xyz> writes: > > On Mon, Dec 19, 2022 at 07:41:27PM +0530, Bharath Rupireddy wrote: > >> 0002 - gets rid of an unnecessary call to BlessTupleDesc() > >> after get_call_result_type(). > > > Hmm. I am not sure whether this is right, actually.. > > Hmm ... at least one of the paths through internal_get_result_type > is intentionally blessing the result tupdesc: > > if (tupdesc->tdtypeid == RECORDOID && > tupdesc->tdtypmod < 0) > assign_record_type_typmod(tupdesc); > > but it's not clear if they all do, and the comments certainly > aren't promising it.
It looks to be safe to get rid of BlessTupleDesc() after get_call_result_type() for the functions that have OUT parameters and return 'record' type. This is because, the get_call_result_type()->internal_get_result_type()->build_function_result_tupdesc_t() returns non-NULL tupdesc for such functions and all the functions that 0002 patch touches are having OUT parameters and their return type is 'record'. I've also verified with Assert(tupdesc->tdtypmod >= 0); - https://github.com/BRupireddy/postgres/tree/test_for_tdypmod_init_v1. -- Bharath Rupireddy PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
