Re: Column Filtering in Logical Replication
От | Amit Kapila |
---|---|
Тема | Re: Column Filtering in Logical Replication |
Дата | |
Msg-id | CAA4eK1L6YTcx=yJfdudr-y98Wcn4rWX4puHGAa2nxSCRb3fzQw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Column Filtering in Logical Replication (Tomas Vondra <tomas.vondra@enterprisedb.com>) |
Ответы |
Re: Column Filtering in Logical Replication
|
Список | pgsql-hackers |
On Fri, Mar 18, 2022 at 8:13 PM Tomas Vondra <tomas.vondra@enterprisedb.com> wrote: > > Ah, thanks for reminding me - it's hard to keep track of all the issues > in threads as long as this one. > > BTW do you have any opinion on the SET COLUMNS syntax? Peter Smith > proposed to get rid of it in [1] but I'm not sure that's a good idea. > Because if we ditch it, then removing the column list would look like this: > > ALTER PUBLICATION pub ALTER TABLE tab; > > And if we happen to add other per-table options, this would become > pretty ambiguous. > > Actually, do we even want to allow resetting column lists like this? We > don't allow this for row filters, so if you want to change a row filter > you have to re-add the table, right? > We can use syntax like: "alter publication pub1 set table t1 where (c2 > 10);" to reset the existing row filter. It seems similar thing works for column list as well ("alter publication pub1 set table t1 (c2) where (c2 > 10)"). If I am not missing anything, I don't think we need additional Alter Table syntax. > So maybe we should just ditch ALTER > TABLE entirely. > Yeah, I agree especially if my above understanding is correct. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: