On Wed, Sep 21, 2022 at 8:08 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Wed, Sep 21, 2022 at 3:09 PM Peter Smith <smithpb2250@gmail.com> wrote:
> >
> > On Wed, Sep 21, 2022 at 3:23 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
> > ...
> >
> > > Can't we use the existing function ReplicationOriginNameForTablesync()
> > > by passing relid as InvalidOid for this purpose? We need a check
> > > inside to decide which name to construct, otherwise, it should be
> > > fine. If we agree with this, then we can change the name of the
> > > function to something like ReplicationOriginNameForLogicalRep or
> > > ReplicationOriginNameForLogicalRepWorkers.
> > >
> >
> > This suggestion attaches special meaning to the reild param.
> >
> > Won't it seem a bit strange for the non-tablesync callers (who
> > probably have a perfectly valid 'relid') to have to pass an InvalidOid
> > relid just so they can format the correct origin name?
> >
>
> For non-tablesync workers, relid should always be InvalidOid. See, how
> we launch apply workers in ApplyLauncherMain(). Do you see any case
> for non-tablesync workers where relid is not InvalidOid?
>
Hmm, my mistake. I was thinking more of all the calls coming from the
subscriptioncmds.c, but now that I look at it maybe none of those has
any relid either.
OK, I can unify the 2 functions as you suggested. I will post another
patch in a few days.
------
Kind Regards,
Peter Smith,
Fujitsu Australia.
