Re: Replace some cstring_to_text to cstring_to_text_with_len

Em qui., 31 de ago. de 2023 às 08:41, John Naylor <
john(dot)naylor(at)enterprisedb(dot)com> escreveu:

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