Re: Rename ExtendedBufferWhat in 16?

From: Andres Freund <andres(at)anarazel(dot)de>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Rename ExtendedBufferWhat in 16?
Date: 2023-08-16 22:49:49
Message-ID: 20230816224949.ebnupxjx5luwu5q6@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2023-08-16 22:54:32 Re: Performance degradation on concurrent COPY into a single relation in PG16.
Previous Message Jacob Champion 2023-08-16 22:11:22 Re: Logging of matching pg_hba.conf entry during auth skips trust auth, potential security issue