Re: Skipping logical replication transactions on subscriber side

On Sat, Jan 15, 2022 at 3:58 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Fri, Jan 14, 2022 at 5:35 PM vignesh C <vignesh21@gmail.com> wrote:
> >
> > Thanks for the updated patch, few minor comments:
> > 1) Should "SKIP" be "SKIP (" here:
> > @@ -1675,7 +1675,7 @@ psql_completion(const char *text, int start, int end)
> >         /* ALTER SUBSCRIPTION <name> */
> >         else if (Matches("ALTER", "SUBSCRIPTION", MatchAny))
> >                 COMPLETE_WITH("CONNECTION", "ENABLE", "DISABLE", "OWNER TO",
> > -                                         "RENAME TO", "REFRESH
> > PUBLICATION", "SET",
> > +                                         "RENAME TO", "REFRESH
> > PUBLICATION", "SET", "SKIP",
> >
>
> Won't the another rule as follows added by patch sufficient for what
> you are asking?
> + /* ALTER SUBSCRIPTION <name> SKIP */
> + else if (Matches("ALTER", "SUBSCRIPTION", MatchAny, "SKIP"))
> + COMPLETE_WITH("(");
>
> I might be missing something but why do you think the handling of SKIP
> be any different than what we are doing for SET?

In case of "ALTER SUBSCRIPTION sub1 SET" there are 2 possible  tab
completion options, user can either specify "ALTER SUBSCRIPTION sub1
SET PUBLICATION pub1" or "ALTER SUBSCRIPTION sub1 SET ( SET option
like STREAMING,etc = 'on')", that is why we have 2 possible options as
below:
postgres=# ALTER SUBSCRIPTION sub1 SET
(            PUBLICATION

Whereas in the case of SKIP there is only one possible tab completion
option i.e XID. We handle similarly in case of WITH option, we specify
"WITH (" in case of tab completion for "CREATE PUBLICATION pub1"
postgres=# CREATE PUBLICATION pub1
FOR ALL TABLES            FOR ALL TABLES IN SCHEMA  FOR TABLE
       WITH (

Regards,
Vignesh