Re: Use get_call_result_type() more widely

On Tue, Dec 20, 2022 at 1:41 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Michael Paquier <michael(at)paquier(dot)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