On Wed, Aug 24, 2022 at 12:15 AM Nathan Bossart <nathandboss...@gmail.com> wrote: > > On Tue, Aug 23, 2022 at 01:03:03PM +0700, John Naylor wrote: > > On Tue, Aug 23, 2022 at 10:32 AM Nathan Bossart > >> Here's a new version of the patch with the 32-bit changes and calls to > >> lfind() removed. > > > > LGTM overall. My plan is to split out the json piece, adding tests for > > that, and commit the infrastructure for it fairly soon. Possible > > bikeshedding: Functions like vector8_eq() might be misunderstood as > > comparing two vectors, but here we are comparing each lane with a > > scalar. I wonder if vector8_eq_scalar() et al might be more clear. > > Good point. I had used vector32_veq() to denote vector comparison, which > would extend to something like vector8_seq(). But that doesn't seem > descriptive enough. It might be worth considering vector8_contains() or > vector8_has() as well. I don't really have an opinion, but if I had to > pick something, I guess I'd choose vector8_contains().
It seems "scalar" would be a bad choice since it already means (confusingly) operating on the least significant element of a vector. I'm thinking of *_has and *_has_le, matching the already existing in the earlier patch *_has_zero. -- John Naylor EDB: http://www.enterprisedb.com
