On Fri, Dec 19, 2025 at 10:40 AM shveta malik <[email protected]> wrote: > > On Fri, Dec 19, 2025 at 9:53 AM Dilip Kumar <[email protected]> wrote: > > > > > 2. Do we want to support multi destination then providing string like > > 'conflict_log_destination = 'log,table,..' make more sense but then we > > would have to store as a string in catalog and parse it everytime we > > insert conflicts or alter subscription OTOH currently I have just > > support single option log/table/both which make things much easy > > because then in catalog we can store as a single char field and don't > > need any parsing. And since the input are taken as a string itself, > > even if in future we want to support more options like 'log,table,..' > > it would be backward compatible with old options. > > I feel, combination of options might be a good idea, similar to how > 'log_destination' provides. But it can be done in future versions and > the first draft can be a simple one. >
Considering the future extension of storing conflict information in multiple places, it would be good to follow log_destination. Yes, it is more work now but I feel that will be future-proof. -- With Regards, Amit Kapila.
