Re: Time delayed LR (WAS Re: logical replication restrictions)

At Tue, 24 Jan 2023 14:22:19 +0530, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote in
> On Tue, Jan 24, 2023 at 12:44 PM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
> >
> > On Tue, Jan 24, 2023 at 5:58 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > >
> > > On Tue, Jan 24, 2023 at 8:15 AM Kyotaro Horiguchi
> > > <horikyota(dot)ntt(at)gmail(dot)com> wrote:
> > > >
> > > > > Attached the updated patch v19.
> > > >
> > > > + maybe_delay_apply(TransactionId xid, TimestampTz finish_ts)
> > > >
> > > > I look this spelling strange. How about maybe_apply_delay()?
> > > >
> > >
> > > +1.
> >
> > It depends on how you read it. I read it like this:
> >
> > maybe_delay_apply === means "maybe delay [the] apply"
> > (which is exactly what the function does)
> >
> > versus
> >
> > maybe_apply_delay === means "maybe [the] apply [needs a] delay"
> > (which is also correct, but it seemed a more awkward way to say it IMO)
> >
>
> This matches more with GUC and all other usages of variables in the
> patch. So, I still prefer the second one.

I read it as "maybe apply [the] delay [to something suggested by the
context]". If we go the first way, I will name it as
"maybe_delay_apply_change" or something that has an extra word.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center