Re: BitmapHeapScan streaming read user and prelim refactoring

On Mon, Aug 26, 2024 at 10:49 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Wed, Jun 19, 2024 at 2:21 PM Melanie Plageman
> > <melanieplageman@gmail.com> wrote:
> >> If we want to make it possible to use no tools and only manually grep
> >> for struct members, that means we can never reuse struct member names.
> >> Across a project of our size, that seems like a very serious
> >> restriction. Adding prefixes in struct members makes it harder to read
> >> code -- both because it makes the names longer and because people are
> >> more prone to abbreviate the meaningful parts of the struct member
> >> name to make the whole name shorter.
>
> > I don't think we should go so far as to never reuse a structure member
> > name. But I also do use 'git grep' a lot to find stuff, and I don't
> > appreciate it when somebody names a key piece of machinery 'x' or 'n'
> > or something, especially when references to that thing could
> > reasonably occur almost anywhere in the source code. So if somebody is
> > creating a struct whose names are fairly generic and reasonably short,
> > I like the idea of using a prefix for those names. If the structure
> > members are things like that_thing_i_stored_behind_the_fridge (which
> > is long) or cytokine (which is non-generic) then they're greppable
> > anyway and it doesn't really matter. But surely changing something
> > like rs_flags to just flags is just making everyone's life harder:
>
> I'm with Robert here: I care quite a lot about the greppability of
> field names.  I'm not arguing for prefixes everywhere, but I don't
> think we should strip out prefixes we've already created, especially
> if the result will be to have extremely generic field names.

Okay, got it -- folks like the prefixes.
I'm picking this patch set back up again after a long pause and I will
restore all prefixes.

What does the rs_* in the HeapScanDescData stand for, though?

- Melanie