Re: Replace some cstring_to_text to cstring_to_text_with_len

From: John Naylor <john(dot)naylor(at)enterprisedb(dot)com>
To: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Replace some cstring_to_text to cstring_to_text_with_len
Date: 2023-08-31 11:41:14
Message-ID: CAFBsxsGXJSLLXy4TA1bW0TzQENbqdAsU-vNE4TZ_5my+KQnQ3g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 31, 2023 at 6:07 PM Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> wrote:
>
> Em qui., 31 de ago. de 2023 às 00:22, Michael Paquier <michael(at)paquier(dot)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.

@@ -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.

--
John Naylor
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2023-08-31 12:37:49 Re: [17] CREATE SUBSCRIPTION ... SERVER
Previous Message Junwang Zhao 2023-08-31 11:35:32 Re: Should we use MemSet or {0} for struct initialization?