On Fri, Oct 1, 2021 at 6:30 AM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > On Fri, Oct 1, 2021 at 5:05 AM Peter Eisentraut > <peter.eisentr...@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.
