Re: BitmapHeapScan streaming read user and prelim refactoring - Mailing list pgsql-hackers

From Tom Lane
Subject Re: BitmapHeapScan streaming read user and prelim refactoring
Date
Msg-id 2767299.1724683755@sss.pgh.pa.us
Whole thread Raw
In response to Re: BitmapHeapScan streaming read user and prelim refactoring  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Jim Jones
Date:
Subject: Re: [PATCH] Add CANONICAL option to xmlserialize
Next
From: Peter Geoghegan
Date:
Subject: Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan