Re: a litter question about mdunlinkfiletag function

>
> You will find other places where relpathperm() is called without having
> a FileTag structure available, e.g. ReorderBufferProcessTXN().
>

I apologize for the confusion. What I meant to say is that in the
mdunlinkfiletag() function, the forknum is currently hardcoded as
MAIN_FORKNUM when calling relpathperm(). While mdunlinkfiletag currently
only handles MAIN_FORKNUM, wouldn’t it be more flexible to retrieve the
forknum from the ftag structure instead?

Bruce Momjian <bruce(at)momjian(dot)us> 于2024年10月15日周二 04:59写道：

> On Mon, Sep 30, 2024 at 10:43:17AM +0800, px shi wrote:
> > Hi, hackers
> >
> > When calculating the path, forknum is hardcoded as MAIN_FORKNUM:
> >
> > /* Compute the path. */
> > p = relpathperm(ftag->rnode, MAIN_FORKNUM);
> >
> >
> > But since the ftag structure already contains forknum:
> >
> > typedef struct FileTag
> > {
> > int16 handler; /* SyncRequestHandler value, saving space */
> > int16 forknum; /* ForkNumber, saving space */
> > RelFileNode rnode;
> > uint32 segno;
> > } FileTag;
> >
> >
> > Wouldn’t it be more flexible to use the value from the ftag structure
> directly?
>
> You will find other places where relpathperm() is called without having
> a FileTag structure available, e.g. ReorderBufferProcessTXN().
>
> --
> Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
> EDB https://enterprisedb.com
>
> When a patient asks the doctor, "Am I going to die?", he means
> "Am I going to die soon?"
>