Re: [Proposal] Level4 Warnings show many shadow vars
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: ranier_gyn@hotmail.com, pgsql-hackers@postgresql.org
Date: 2019-12-09T21:49:42Z
Lists: pgsql-hackers
On 2019-Dec-09, Kyotaro Horiguchi wrote: > > >BTW, if we do go forward with changing the RedoRecPtr uses, I'm not > > >in love with "XRedoRecPtr" as a replacement parameter name; it conveys > > >nothing much, and the "X" prefix is already overused in that area of > > >the code. Perhaps "pRedoRecPtr" would be a better choice? Or maybe > > >make the local variables be all-lower-case "redorecptr", which would > > >fit well in context in places like > > pRedoRecPtr, It's perfect for me. > > Anyway I strongly object to the name 'pRedoRecPtr', which suggests as > if it is a C-pointer to some variable. (And I believe we use Hungarian > notation only if we don't have a better way...) LatestRedoRecPtr > looks better to me. We have a not-consistently-used convention that names in CamelCase are used for global variables. Naming a function parameter in that style seems pointlessly confusing. I would rather use redorecptr as Tom suggested, which fits with the style used for the other arguments of that function. BTW prepending an X or a p looks like minimum effort... I'd stay away from that. It's probably a lost cause to enforce such a style with ironclad consistency, but I suggest we make at least a token effort at it, and keep our source as least confusing as possible. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Remove shadow variables linked to RedoRecPtr in xlog.c
- 668365014d7b 11.7 landed
- 35c01529b8c9 12.2 landed
- 70116493a8e0 13.0 landed
-
Fix calculation for WAL segment recycling and removal
- d9fadbf13103 12.0 cited