Re: Add support for specifying tables in pg_createsubscriber.

On Fri, 8 Aug 2025 at 13:47, Zhijie Hou (Fujitsu)
<houzj(dot)fnst(at)fujitsu(dot)com> wrote:
>
> On Wednesday, August 6, 2025 7:23 PM vignesh C <vignesh21(at)gmail(dot)com> wrote:
> > On Fri, 1 Aug 2025 at 13:33, Zhijie Hou (Fujitsu) <houzj(dot)fnst(at)fujitsu(dot)com>
> > wrote:
> > >
> > > On Monday, July 28, 2025 1:07 PM Hayato Kuroda (Fujitsu)
> > <kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
> > > >
> > > > Dear Shubham,
> > > >
> > > > > The attached patch introduces a new '--table' option that can be
> > > > > specified after each '--database' argument.
> > > >
> > > > Do we have another example which we consider the ordering of
> > > > options? I'm unsure for it. Does getopt_long() always return parsed
> > > > options with the specified order?
> > > >
> > > > > The syntax is like that used in 'vacuumdb'
> > > > > and supports multiple '--table' arguments per database, including
> > > > > optional column lists and row filters.
> > > >
> > > > Vacuumdb nor pg_restore do not accept multiple --database, right?
> > > > I'm afraid that current API has too complex.
> > >
> > > We have another example to consider: pg_amcheck, which allows users to
> > > specify multiple databases. Following this precedent, it may be
> > > beneficial to adopt a similar style in pg_createsubscriber. E.g.,
> > > Users could specify tables using database-qualified names, such as:
> > >
> > > ./pg_createsubscriber --database db1 --table 'db1.public.t1' --table
> > > 'db1.public.t2(a,b) WHERE a > 100' --database db2 --table 'db2.public.t3'
> >
> > pg_amcheck allows specifying tables as a pattern, the below note is from [1]:
> > Patterns may be unqualified, e.g. myrel*, or they may be schema-qualified, e.g.
> > myschema*.myrel* or database-qualified and schema-qualified, e.g.
> > mydb*.myschema*.myrel*. A database-qualified pattern will add matching
> > databases to the list of databases to be checked.
> >
> > In pg_createsubscriber will it be using the exact spec of pg_amcheck or will the
> > user have to give fully qualified names?
>
> Both options are acceptable to me. Fully qualified names might be more familiar
> to users of publication DDLs, given that regex is not supported for these
> statements. So, I personally think that if we want to start with something
> simple, using fully qualified names is sensible, with the possibility to extend
> this functionality later if needed.

+1 for implementing this way.

Regards,
Vignesh