On Fri, Oct 1, 2021 at 6:30 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Fri, Oct 1, 2021 at 5:05 AM Peter Eisentraut
> <peter.eisentraut@enterprisedb.com> wrote:
> >
> > On 30.09.21 07:45, Masahiko Sawada wrote:
> > > I've attached updated patches that incorporate all comments I got so
> > > far. Please review them.
> >
> > I'm uneasy about the way the xids-to-be-skipped are presented as
> > subscriptions options, similar to settings such as "binary". I see how
> > that is convenient, but it's not really the same thing, in how you use
> > it, is it? Even if we share some details internally, I feel that there
> > should be a separate syntax somehow.
>
> Since I was thinking that ALTER SUBSCRIPTION ... SET is used to alter
> parameters originally set by CREATE SUBSCRIPTION, in the first several
> version patches it added a separate syntax for this feature like ALTER
> SUBSCRIPTION ... SET SKIP TRANSACTION xxx. But Amit was concerned
> about an additional syntax and consistency with disable_on_error[1]
> which is proposed by Mark Diliger[2], so I’ve changed it to a
> subscription option.
>
Yeah, the basic idea is that this is not the only option we will
support for taking actions on error/conflict. For example, we might
want to disable subscriptions or allow skipping transactions based on
XID, LSN, etc. So, developing separate syntax for each of the options
doesn't seem like a good idea. However considering Peter's point, how
about something like:
Alter Subscription <sub_name> On Error ( subscription_parameter [=
value] [, ... ] );
OR
Alter Subscription <sub_name> On Conflict ( subscription_parameter [=
value] [, ... ] );
--
With Regards,
Amit Kapila.