RE: Add support for specifying tables in pg_createsubscriber.

From: "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>
To: vignesh C <vignesh21(at)gmail(dot)com>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Shubham Khanna <khannashubham1197(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: RE: Add support for specifying tables in pg_createsubscriber.
Date: 2025-08-08 08:16:57
Message-ID: OS0PR01MB5716203AF50EFDF0256C5452942FA@OS0PR01MB5716.jpnprd01.prod.outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

Best Regards,
Hou zj

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Shinya Kato 2025-08-08 08:34:03 Re: Enhance statistics reset functions to return reset timestamp
Previous Message Michael Paquier 2025-08-08 08:06:16 Re: Enhance statistics reset functions to return reset timestamp