On Tue, Oct 26, 2021 at 2:27 PM Greg Nancarrow <gregn4...@gmail.com> wrote: > > On Tue, Oct 26, 2021 at 5:16 PM Amit Kapila <amit.kapil...@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.
