Обсуждение: Rename ExtendedBufferWhat in 16?
Hi Commit 31966b15 invented a way for functions dealing with relation extension to accept a Relation in online code and an SMgrRelation in recovery code (instead of using the earlier FakeRelcacheEntry concept). It seems highly likely that future new bufmgr.c interfaces will face the same problem, and need to do something similar. Let's generalise the names so that each interface doesn't have to re-invent the wheel? ExtendedBufferWhat is also just not a beautiful name. How about BufferedObjectSelector? That name leads to macros BOS_SMGR() and BOS_REL(). Could also be BufMgrObject/BMO, ... etc etc. This is from a patch-set that I'm about to propose for 17, which needs one of these too, hence desire to generalise. But if we rename them in 17, then AM authors, who are likely to discover and make use of this interface, would have to use different names for 16 and 17.
Вложения
Hi, On 2023-08-12 12:29:05 +1200, Thomas Munro wrote: > Commit 31966b15 invented a way for functions dealing with relation > extension to accept a Relation in online code and an SMgrRelation in > recovery code (instead of using the earlier FakeRelcacheEntry > concept). It seems highly likely that future new bufmgr.c interfaces > will face the same problem, and need to do something similar. Let's > generalise the names so that each interface doesn't have to re-invent > the wheel? ExtendedBufferWhat is also just not a beautiful name. How > about BufferedObjectSelector? That name leads to macros BOS_SMGR() > and BOS_REL(). Could also be BufMgrObject/BMO, ... etc etc. I like the idea of generalizing it. I somehow don't quite like BOS*, but I can't really put into words why, so... > This is from a patch-set that I'm about to propose for 17, which needs > one of these too, hence desire to generalise. But if we rename them > in 17, then AM authors, who are likely to discover and make use of > this interface, would have to use different names for 16 and 17. Makes sense to me. Greetings, Andres Freund
On Thu, Aug 17, 2023 at 10:49 AM Andres Freund <andres@anarazel.de> wrote: > On 2023-08-12 12:29:05 +1200, Thomas Munro wrote: > > Commit 31966b15 invented a way for functions dealing with relation > > extension to accept a Relation in online code and an SMgrRelation in > > recovery code (instead of using the earlier FakeRelcacheEntry > > concept). It seems highly likely that future new bufmgr.c interfaces > > will face the same problem, and need to do something similar. Let's > > generalise the names so that each interface doesn't have to re-invent > > the wheel? ExtendedBufferWhat is also just not a beautiful name. How > > about BufferedObjectSelector? That name leads to macros BOS_SMGR() > > and BOS_REL(). Could also be BufMgrObject/BMO, ... etc etc. > > I like the idea of generalizing it. I somehow don't quite like BOS*, but I > can't really put into words why, so... Do you like BufferManagerRelation, BMR_REL(), BMR_SMGR()? Just BM_ would clash with the flag namespace. > > This is from a patch-set that I'm about to propose for 17, which needs > > one of these too, hence desire to generalise. But if we rename them > > in 17, then AM authors, who are likely to discover and make use of > > this interface, would have to use different names for 16 and 17. > > Makes sense to me. Does anyone else want to object? Restating the case in brief: commit 31966b15's naming is short-sighted and likely to lead to a proliferation of similar things or a renaming in later releases.
On Wed, Aug 16, 2023 at 4:32 PM Thomas Munro <thomas.munro@gmail.com> wrote: > Does anyone else want to object? Restating the case in brief: commit > 31966b15's naming is short-sighted and likely to lead to a > proliferation of similar things or a renaming in later releases. +1 to proceeding with this change. -- Peter Geoghegan
On 2023-08-17 11:31:27 +1200, Thomas Munro wrote: > On Thu, Aug 17, 2023 at 10:49 AM Andres Freund <andres@anarazel.de> wrote: > > On 2023-08-12 12:29:05 +1200, Thomas Munro wrote: > > > Commit 31966b15 invented a way for functions dealing with relation > > > extension to accept a Relation in online code and an SMgrRelation in > > > recovery code (instead of using the earlier FakeRelcacheEntry > > > concept). It seems highly likely that future new bufmgr.c interfaces > > > will face the same problem, and need to do something similar. Let's > > > generalise the names so that each interface doesn't have to re-invent > > > the wheel? ExtendedBufferWhat is also just not a beautiful name. How > > > about BufferedObjectSelector? That name leads to macros BOS_SMGR() > > > and BOS_REL(). Could also be BufMgrObject/BMO, ... etc etc. > > > > I like the idea of generalizing it. I somehow don't quite like BOS*, but I > > can't really put into words why, so... > > Do you like BufferManagerRelation, BMR_REL(), BMR_SMGR()? > > Just BM_ would clash with the flag namespace. I like BMR better!
On Thu, Aug 17, 2023 at 12:42 PM Andres Freund <andres@anarazel.de> wrote: > I like BMR better! Thanks Andres and Peter. Here's a version like that. I hesitated about BufMgrRelation instead, but neither name appears in code currently and full words are better. In this version I also renamed all the 'eb' variables to 'bmr'. If there are no more comments or objections, I'd like to push this to 16 and master in a day or two.