Rename 'lpp' to 'lp' in heapam.c
Hi, I just found the naming of the ItemId variables is not consistent in heapam.c. There are 13 'lpp's and 112 'lp's. Technically 'lpp' is correct as ItemId is a line pointer's pointer and there used to be code like "++lpp" for line pointer array iteration. Now that all the "++lpp" code has been removed and there are 100+ more occurrences of 'Ip' than 'lpp', I suggest we change 'lpp' to 'lp' to make things consistent and avoid confusion. Best Regards, Zian Wang v-1-0001-Rename-lpp-to-lp-in-heapam.c.patch Description: Binary data
Re: Rename 'lpp' to 'lp' in heapam.c
On Wed, 3 May 2023 at 12:16, Yaphters W wrote: > I just found the naming of the ItemId variables is not consistent in > heapam.c. There are 13 'lpp's and 112 'lp's. Technically 'lpp' is correct as > ItemId is a line pointer's pointer and there used to be code like "++lpp" for > line pointer array iteration. Now that all the "++lpp" code has been removed > and there are 100+ more occurrences of 'Ip' than 'lpp', I suggest we change > 'lpp' to 'lp' to make things consistent and avoid confusion. I don't really agree that one is any more correct than the other. I also don't think we should be making changes like this as doing this may give some false impression that we have some standard to follow here that a local variable of a given type must be given a certain name. To comply with such a standard seems like it would take close to an endless number of patches which would just result in wasted reviewer and committer time and give us nothing but pain while back patching. -1 from me. David
Re: Rename 'lpp' to 'lp' in heapam.c
On Tue, May 2, 2023 at 10:18 PM David Rowley wrote: > I don't really agree that one is any more correct than the other. I > also don't think we should be making changes like this as doing this > may give some false impression that we have some standard to follow > here that a local variable of a given type must be given a certain > name. To comply with such a standard seems like it would take close to > an endless number of patches which would just result in wasted > reviewer and committer time and give us nothing but pain while back > patching. > > -1 from me. I agree with David. This seems like pointless code churn. -- Robert Haas EDB: http://www.enterprisedb.com
