Re: row filtering for logical replication
От | Dilip Kumar |
---|---|
Тема | Re: row filtering for logical replication |
Дата | |
Msg-id | CAFiTN-vkDeP7+fhDcyPK7E_Hd+8SupkHrZc=Aq=xYSzhwAKGkQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: row filtering for logical replication (Amit Kapila <amit.kapila16@gmail.com>) |
Список | pgsql-hackers |
On Mon, Nov 29, 2021 at 5:40 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > I don't think it is a good idea to combine the row-filter from the > > > publication that publishes just 'insert' with the row-filter that > > > publishes 'updates'. We shouldn't apply the 'insert' filter for > > > 'update' and similarly for publication operations. We can combine the > > > filters when the published operations are the same. So, this means > > > that we might need to cache multiple row-filters but I think that is > > > better than having another restriction that publish operation 'insert' > > > should also honor RI columns restriction. > > > > I am just wondering that if we don't combine filter in the above case > > then what data we will send to the subscriber if the operation is > > "UPDATE tbl1 SET a = 2, b=3", so in this case, we will apply only the > > update filter i.e. a > 1 so as per that this will become the INSERT > > operation because the old row was not passing the filter. > > > > If we want, I think for inserts (new row) we can consider the insert > filter as well but that makes it tricky to explain. I feel we can > change it later as well if there is a valid use case for this. What do > you think? Yeah, that makes sense. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: