Re: Support isEmptyStringInfo

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: robertmhaas(at)gmail(dot)com, ashutosh(dot)bapat(dot)oss(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org, ashutosh(dot)bapat(at)enterprisedb(dot)com
Subject: Re: Support isEmptyStringInfo
Date: 2022-03-24 01:37:37
Message-ID: 20220324.103737.783084933568509720.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Wed, 23 Mar 2022 10:13:43 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > I think that the code is perfectly readable as it is and that this
> > change makes it less so.
>
> Yeah, after a quick look through this patch I'm unimpressed too.
> The new code is strictly longer, and it requires the introduction
> of distracting "!" and "&" operators in many places.

The struct members are not private at all. In that sense StringInfo
is not a kind of class of C/Java but like a struct of C/C++ at least
to me. I think encapsulating only ".len == 0" doesn't help. Already
in many places we pull out buf.data to use it separately from buf, we
have a dozen of instances of "buf.len (<|>|<=|>=) <some length>" and
even "buf.data[buf.len - 1] == '\n'"

About read-easiness, isEmptyStringInfo(str) slightly spins my eyes
than str->len == 0.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2022-03-24 01:47:58 Re: pg_stat_reset_single_*_counters vs pg_stat_database.stats_reset
Previous Message Tom Lane 2022-03-24 01:20:47 Re: Fix overflow in DecodeInterval