On Wed, Dec 23, 2020 at 10:42 AM Kyotaro Horiguchi <horikyota....@gmail.com> wrote: > > At Wed, 23 Dec 2020 04:22:19 +0000, "tsunakawa.ta...@fujitsu.com" > <tsunakawa.ta...@fujitsu.com> wrote in > > From: Amit Kapila <amit.kapil...@gmail.com> > > > + /* Get the number of blocks for a relation's fork */ > > > + block[i][j] = smgrnblocks(smgr_reln[i], j, &cached); > > > + > > > + if (!cached) > > > + goto buffer_full_scan; > > > > > > Why do we need to use goto here? We can simply break from the loop and > > > then check if (cached && nBlocksToInvalidate < > > > BUF_DROP_FULL_SCAN_THRESHOLD). I think we should try to avoid goto if > > > possible without much complexity. > > > > That's because two for loops are nested -- breaking there only exits the > > inner loop. (I thought the same as you at first... And I understand some > > people have alergy to goto, I think modest use of goto makes the code > > readable.) > > I don't strongly oppose to goto's but in this case the outer loop can > break on the same condition with the inner loop, since cached is true > whenever the inner loop runs to the end. It is needed to initialize > the variable cache with true, instead of false, though. >
+1. I think it is better to avoid goto here as it can be done without introducing any complexity or making code any less readable. -- With Regards, Amit Kapila.
