Re: Use get_call_result_type() more widely - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Use get_call_result_type() more widely
Date
Msg-id 1175696.1671552729@sss.pgh.pa.us
Whole thread Raw
In response to Re: Use get_call_result_type() more widely  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: Use get_call_result_type() more widely  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> writes:
> On Tue, Dec 20, 2022 at 1:41 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Hmm ... at least one of the paths through internal_get_result_type
>> is intentionally blessing the result 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.

I think it's an absolutely horrid idea for callers to depend on
such details of get_call_result_type's behavior --- especially
when there is no function documentation promising it.

If we want to do something here, the thing to do would be to
guarantee in get_call_result_type's API spec that any returned
tupledesc is blessed.  However, that might make some other
cases slower, if they don't need that.

On the whole, I'm content to leave the BlessTupleDesc calls in
these callers.  They are cheap enough if the tupdesc is already
blessed.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: appendBinaryStringInfo stuff
Next
From: Andres Freund
Date:
Subject: Re: meson files copyright