On Sun, May 8, 2022 at 12:39 PM Dilip Kumar <dilipbal...@gmail.com> wrote: > > On Sat, May 7, 2022 at 9:38 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Fri, May 6, 2022 at 10:21 PM Zheng Li <zhengl...@gmail.com> wrote: > > > > > > > Attached is a set of two patches as an attempt to evaluate this > > > > approach. > > > > > > > > > > Thanks for exploring this direction. > > > > > > I read the deparsing thread and your patch. Here is my thought: > > > 1. The main concern on maintainability of the deparsing code still > > > applies if we want to adapt it for DDL replication. > > > > > > > I agree that it adds to our maintainability effort, like every time we > > enhance any DDL or add a new DDL that needs to be replicated, we > > probably need to change the deparsing code. But OTOH this approach > > seems to provide better flexibility. So, in the long run, maybe the > > effort is worthwhile. I am not completely sure at this stage which > > approach is better but I thought it is worth evaluating this approach > > as Alvaro and Robert seem to prefer this idea. > > +1, IMHO with deparsing logic it would be easy to handle the mixed DDL > commands like ALTER TABLE REWRITE. But the only thing is that we will > have to write the deparsing code for all the utility commands so there > will be a huge amount of new code to maintain.
I haven't gone through the entire thread, just trying to understand the need of deparsing logic - do we need the DDL query text to be sent to subscribers? If yes, why can't we WAL log the DDL query text as-is and the logical decoding can send those to subscribers, as-is or in a modified form? Or log the DDLs to a separate log on disk? Regards, Bharath Rupireddy.
