Date: Tue, 19 Jan 2021 17:38:19 +0100
From: David Fetter <david@fetter.org>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
	Tom Lane <tgl@sss.pgh.pa.us>,
	Daniel Verite <daniel@manitou-mail.org>,
	PostgreSQL Development <pgsql-hackers@postgresql.org>,
	Vik Fearing <vik@postgresfriends.org>
Subject: Re: popcount
Message-ID: <20210119163818.GE8721@fetter.org>
References: <20201230105535.GJ13234@fetter.org>
 <5ea2932e-50f5-4a74-9550-5e3291b6652b@manitou-mail.org>
 <20201230164108.GK13234@fetter.org>
 <eb416bd3-9ee2-8a81-8cd4-d61baaf93ec2@enterprisedb.com>
 <20210111161354.GA8721@fetter.org>
 <e48355d3-efaf-e762-fffa-4b2191680292@enterprisedb.com>
 <338981.1610984050@sss.pgh.pa.us>
 <d33d668b-bf70-126d-9ca3-ad5a50488091@enterprisedb.com>
 <CA+Tgmoa18D-8FvtBE3-dJHDTX6A33OeAmRKa6R7+i8-E_o1G-w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CA+Tgmoa18D-8FvtBE3-dJHDTX6A33OeAmRKa6R7+i8-E_o1G-w@mail.gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

On Tue, Jan 19, 2021 at 07:58:12AM -0500, Robert Haas wrote:
> On Tue, Jan 19, 2021 at 3:06 AM Peter Eisentraut
> <peter.eisentraut@enterprisedb.com> wrote:
> > On 2021-01-18 16:34, Tom Lane wrote:
> > > Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> > >> [ assorted nits ]
> > >
> > > At the level of bikeshedding ... I quite dislike using the name "popcount"
> > > for these functions.  I'm aware that some C compilers provide primitives
> > > of that name, but I wouldn't expect a SQL programmer to know that;
> > > without that context the name seems pretty random and unintuitive.
> > > Moreover, it invites confusion with SQL's use of "pop" to abbreviate
> > > "population" in the statistical aggregates, such as var_pop().
> >
> > I was thinking about that too, but according to
> > <https://en.wikipedia.org/wiki/Hamming_weight>, popcount is an accepted
> > high-level term, with "pop" also standing for "population".
> 
> Yeah, I am not sure that it's going to be good to invent our own
> name for this, although maybe. But at least I think we should make
> sure there are some good comments in an easily discoverable place.
> Some people seem to think every programmer in the universe should
> know what things like popcount() and fls() and ffs() and stuff like
> that are, but it's far from obvious and I often have to refresh my
> memory.  Let's make it easy for someone to figure out, if they don't
> know already.

I went with count_set_bits() for the next version, and I hope that
helps clarify what it does.

> Like just a comment that says "this returns the number of 1 bits in
> the integer supplied as an argument" or something can save somebody
> a lot of trouble.

You bring up an excellent point, which is that our builtin functions
could use a lot more documentation directly to hand than they now
have.  For example, there's a lot of needless ambiguity created by
function comments which leave it up in the air as to which positional
argument does what in functions like string_to_array, which take
multiple arguments. I'll try to get a patch in for the next CF with a
fix for that, and a separate one that doesn't put it on people to use
\df+ to find the comments we do provide. There have been proposals for
including an optional space for COMMENT ON in DDL, but I suspect that
those won't fly unless and until they make their way into the
standard.

Best,
David.
-- 
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate