Re: BitmapHeapScan streaming read user and prelim refactoring

Thanks for taking a look at my patches, Álvaro!

On Wed, Jun 19, 2024 at 12:51 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>
> On 2024-Jun-14, Melanie Plageman wrote:
>
> > Subject: [PATCH v21 12/20] Update variable names in bitmap scan descriptors
> >
> > The previous commit which added BitmapTableScanDesc and
> > BitmapHeapScanDesc used the existing member names from TableScanDescData
> > and HeapScanDescData for diff clarity. This commit renames the members
> > -- in many cases by removing the rs_ prefix which is not relevant or
> > needed here.
>
> *Cough* Why? It makes grepping for struct members useless. I'd rather
> keep these prefixes, as they allow easier code exploration. (Sometimes
> when I need to search for uses of some field with a name that's too
> common, I add a prefix to the name and let the compiler guide me to
> them. But that's a waste of time ...)

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.

While I understand we as a project want to make it possible to hack on
Postgres without an IDE or a set of vim plugins a mile long, I also
think we have to make some compromises for readability. Most commonly
used text editors have LSP (language server protocol) support and
should allow for meaningful identification of the usages of a struct
member even if it has the same name as a member of another struct.

That being said, I'm not unreasonable. If we have decided we can not
reuse struct member names, I will change my patch.

- Melanie