Thread: Rename ExtendedBufferWhat in 16?

Rename ExtendedBufferWhat in 16?

From
Thomas Munro
Date:
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.

Attachment

Re: Rename ExtendedBufferWhat in 16?

From
Andres Freund
Date:
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



Re: Rename ExtendedBufferWhat in 16?

From
Thomas Munro
Date:
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.



Re: Rename ExtendedBufferWhat in 16?

From
Peter Geoghegan
Date:
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



Re: Rename ExtendedBufferWhat in 16?

From
Andres Freund
Date:
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!



Re: Rename ExtendedBufferWhat in 16?

From
Thomas Munro
Date:
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.

Attachment