Re: DropRelFileLocatorBuffers

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: robertmhaas(at)gmail(dot)com
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: DropRelFileLocatorBuffers
Date: 2022-07-12 02:25:31
Message-ID: 20220712.112531.323920953940930135.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Mon, 11 Jul 2022 13:51:12 -0400, Robert Haas <robertmhaas(at)gmail(dot)com> wrote in
> On Fri, Jul 8, 2022 at 1:59 AM Kyotaro Horiguchi
> <horikyota(dot)ntt(at)gmail(dot)com> wrote:
> > The function CreateAndCopyRelationData exists since before b0a55e4329
> > but renamed since it takes RelFileLocators.
>
> I'm not very sold on this. I think that the places where you've
> replaced RelFileLocator with just RelFile in various functions might
> be an improvement, but the places where you've replaced Relation with
> RelFile seem to me to be worse. I don't really see that there's
> anything wrong with names like CreateAndCopyRelationData or
> FlushRelationsAllBuffers, and in general I prefer function names that
> are made up of whole words rather than parts of words.

Fair enough. My first thought was that Relation can represent both
Relation and "RelFile" but in the patch I choosed to make distinction
between them by associating respectively to the types of the primary
parameter (Relation or RelFileLocator). So I'm fine with Relation
instead since I see it more intuitive than RelFileLocator in the
function names.

The attached is that.

> > While working on this, I found that the following coment is wrong.
..
> I committed this.

Thanks!

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

Attachment Content-Type Size
v2-0001-Rename-some-RelFileLocator-functions.patch text/x-patch 13.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2022-07-12 03:12:55 Re: Handle infinite recursion in logical replication setup
Previous Message Melanie Plageman 2022-07-12 02:22:28 Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)