Re: Replace some cstring_to_text to cstring_to_text_with_len

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: Replace some cstring_to_text to cstring_to_text_with_len
Дата
Msg-id df85d567-1fc2-39b3-f982-73d38aea09d7@dunslane.net
обсуждение исходный текст
Ответ на Re: Replace some cstring_to_text to cstring_to_text_with_len  (John Naylor <john.naylor@enterprisedb.com>)
Ответы Re: Replace some cstring_to_text to cstring_to_text_with_len  (Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>)
Re: Replace some cstring_to_text to cstring_to_text_with_len  (Ranier Vilela <ranier.vf@gmail.com>)
Список pgsql-hackers


On 2023-08-31 Th 07:41, John Naylor wrote:

On Thu, Aug 31, 2023 at 6:07 PM Ranier Vilela <ranier.vf@gmail.com> wrote:
>
> Em qui., 31 de ago. de 2023 às 00:22, Michael Paquier <michael@paquier.xyz> escreveu:
>>
>> On Wed, Aug 30, 2023 at 03:00:13PM -0300, Ranier Vilela wrote:
>> > cstring_to_text has a small overhead, because call strlen for
>> > pointer to char parameter.
>> >
>> > Is it worth the effort to avoid this, where do we know the size of the
>> > parameter?
>>
>> Are there workloads where this matters?
>
> None, but note this change has the same spirit of 8b26769bc.

- return cstring_to_text("");
+ return cstring_to_text_with_len("", 0);

This looks worse, so we'd better be getting something in return.


I agree this is a bit ugly. I wonder if we'd be better off creating a function that returned an empty text value, so we'd just avoid converting the empty cstring altogether and say:

  return empty_text();


cheers


andrew



--
Andrew Dunstan
EDB: https://www.enterprisedb.com

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ashutosh Bapat
Дата:
Сообщение: Re: persist logical slots to disk during shutdown checkpoint
Следующее
От: Amit Langote
Дата:
Сообщение: Re: remaining sql/json patches