Re: Use get_call_result_type() more widely

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Use get_call_result_type() more widely
Дата
Msg-id 1175696.1671552729@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Use get_call_result_type() more widely  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Ответы Re: Use get_call_result_type() more widely  (Michael Paquier <michael@paquier.xyz>)
Список 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 по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: appendBinaryStringInfo stuff
Следующее
От: Andres Freund
Дата:
Сообщение: Re: meson files copyright