On Tue, Oct 26, 2021 at 2:27 PM Greg Nancarrow <gregn4422@gmail.com> wrote:
>
> On Tue, Oct 26, 2021 at 5:16 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > I agree that we will need a separate syntax for conflict resolution
> > but there is some similarity in what I proposed above (On
> > Error/Conflict [1]) with the existing syntax of Insert ... On
> > Conflict. I understand that here the context is different and we are
> > storing this information in the catalog but still there is some syntax
> > similarity and it will avoid adding new syntax variants.
> >
>
> The problem I see with the suggested syntax:
>
> Alter Subscription <sub_name> On Error ( subscription_parameter [=
> value] [, ... ] );
> OR
> Alter Subscription <sub_name> On Conflict ( subscription_parameter [=
> value] [, ... ] );
>
> is that "On Error ..." and "On Conflict" imply an action to be done on
> a future condition (Error/Conflict), whereas at least in this case
> (skip_xid) it's only AFTER the problem condition has occurred that we
> know the XID of the failed transaction that we want to skip. So that
> syntax looks a little confusing to me. Unless you had something else
> in mind on how it would work?
>
You have a point. The other alternatives on this line could be:
Alter Subscription <sub_name> SKIP ( subscription_parameter [=value] [, ... ] );
where subscription_parameter can be one of:
xid = <xid_val>
lsn = <lsn_val>
...
Instead of using Skip, we can use WITH as used in Alter Database
syntax but we are already using WITH in Create Subscription for a
different purpose, so that may not be a very good idea.
The basic idea is that I am trying to use options here rather than a
keyword-based syntax as there can be multiple such options.
--
With Regards,
Amit Kapila.
