Re: Replace some cstring_to_text to cstring_to_text_with_len

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, 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 12:51:02
Message-ID: df85d567-1fc2-39b3-f982-73d38aea09d7@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 2023-08-31 Th 07:41, John Naylor wrote:
>
> 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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2023-08-31 12:57:27 Re: remaining sql/json patches
Previous Message Ashutosh Bapat 2023-08-31 12:42:32 Re: persist logical slots to disk during shutdown checkpoint