Re: Column Filtering in Logical Replication
От | Alvaro Herrera |
---|---|
Тема | Re: Column Filtering in Logical Replication |
Дата | |
Msg-id | 202112131744.kw5vn6x4yvzo@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Column Filtering in Logical Replication (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: Column Filtering in Logical Replication
|
Список | pgsql-hackers |
On 2021-Dec-10, Alvaro Herrera wrote: > Actually it's not so easy to implement. So I needed to add "sub object id" support for pg_publication_rel objects in pg_depend / dependency.c. What I have now is partial (the describe routines need patched) but it's sufficient to show what's needed. In essence, we now set these depend entries with column numbers, so that they can be dropped independently; when the drop comes, the existing pg_publication_rel row is modified to cover the remaining columns. As far as I can tell, it works correctly. There is one policy decision to make: what if ALTER TABLE drops the last remaining column in the publication? I opted to raise a specific error in this case, though we could just the same opt to drop the relation from the publication. Are there opinions on this? This version incorporates the fixups Peter submitted, plus some other fixes of my own. Notably, as Peter also mentioned, I changed pg_publication_rel.prattrs to store int2vector rather than an array of column names. This makes for better behavior if columns are renamed and things like that, and also we don't need to be so cautious about quoting. It does mean we need a slightly more complicated query in a couple of spots, but that should be okay. -- Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/ "Always assume the user will do much worse than the stupidest thing you can imagine." (Julien PUYDT)
Вложения
В списке pgsql-hackers по дате отправления: