On Wed, May 11, 2022 at 6:15 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Wed, May 11, 2022 at 1:09 PM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > > > On Mon, May 9, 2022 at 6:05 PM Alvaro Herrera <alvhe...@alvh.no-ip.org> > > wrote: > > > > > > On 2022-May-08, Dilip Kumar wrote: > > > > > > > > The code in test_ddl_deparse is a pretty lame start, not nearly good > > > enough by a thousand miles. My real intention was to have a test > > > harness that would first run a special SQL script to install DDL > > > capture, then run all the regular src/test/regress scripts, and then at > > > the end ensure that all the DDL scripts were properly reproduced -- for > > > example transmit them to another database, replay them there, and dump > > > both databases and compare them. However, there were challenges which I > > > no longer remember and we were unable to complete this, and we are where > > > we are. > > > > I think the regression test suite improvements in these few years make > > it easier to implement such regression tests in order to check not > > only the existing commands but also future changes. I'll try it if no > > one is working on it, and let us see if there are challenges. > > > > I think it is a good idea to give it a try. However, one point to note > in this regard is that if we decide to use deparsing for DDL logical > replication then the tests for logical replication will automatically > test all the deparsing code.
Do you mean that in tests for logical replication we run regression tests on the publisher and check if relations are created/altered/dropped expectedly on the subscriber? If we rely on tests for logical replication, I think logical replication will have to support all future DDL changes/features. Regards, -- Masahiko Sawada EDB: https://www.enterprisedb.com/
