Re: Replace some cstring_to_text to cstring_to_text_with_len
От | Ranier Vilela |
---|---|
Тема | Re: Replace some cstring_to_text to cstring_to_text_with_len |
Дата | |
Msg-id | CAEudQAoRsmZ2VZXiN8gdt5r=zT2a-+63L1siZq0jBeGirQ_v_g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Replace some cstring_to_text to cstring_to_text_with_len (John Naylor <john.naylor@enterprisedb.com>) |
Список | pgsql-hackers |
Em qui., 31 de ago. de 2023 às 08:41, John Naylor <john.naylor@enterprisedb.com> escreveu:
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.
Per suggestion by Andrew Dustan, I provided a new function.
@@ -360,7 +360,7 @@ pg_tablespace_location(PG_FUNCTION_ARGS)
sourcepath)));
targetpath[rllen] = '\0';
- PG_RETURN_TEXT_P(cstring_to_text(targetpath));
+ PG_RETURN_TEXT_P(cstring_to_text_with_len(targetpath, rllen));
This could be a worthwhile cosmetic improvement if the nul-terminator (and space reserved for it, and comment explaining that) is taken out as well, but the patch didn't bother to do that.
Thanks for the tip.
Please see a new version of the patch in the Andrew Dunstan, reply.
best regards,
Ranier Vilela
В списке pgsql-hackers по дате отправления: