Re: row filtering for logical replication
От | Peter Smith |
---|---|
Тема | Re: row filtering for logical replication |
Дата | |
Msg-id | CAHut+PtQE4h8575abXDV+R0Km1RK916iSvbE7shBppO7M-itjw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: row filtering for logical replication (Amit Kapila <amit.kapila16@gmail.com>) |
Список | pgsql-hackers |
On Tue, Nov 23, 2021 at 10:52 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Tue, Nov 23, 2021 at 4:58 PM Ajin Cherian <itsajin@gmail.com> wrote: > > > > Attaching a new patchset v41 which includes changes by both Peter and myself. > > > ... > I suggest at this stage we can combine 0001, 0003, and 0004. Then move > pg_dump and psql (describe.c) related changes to 0002 and make 0002 as > the last patch in the series. This will help review backend changes > first and then we can look at client-side changes. > The patch combining and reordering was as suggested. BEFORE: v41-0001 Euler's main patch v41-0002 Tab-complete v41-0003 ExprState cache v41-0004 OR/AND v41-0005 Validation walker v41-0006 new/old tuple updates AFTER: v42-0001 main patch <== v41-0001 + v41-0003 + v41-0004 v42-0002 validation walker <== v41-0005 v42-0003 new/old tuple updates <== v41-0006 v42-0004 tab-complete and pgdump <== v41-0002 (plus pgdump code from v41-0001) ~ Please note, I did not remove the describe.c changes from the v42-0001 patch at this time. I left this as-is because I felt the ability for psql \d+ or \dRp+ etc to display the current row-filter is *essential* functionality to be able to test and debug the 0001 patch properly. ------ Kind Regards, Peter Smith. Fujitsu Australia
В списке pgsql-hackers по дате отправления: