Re: Column Filtering in Logical Replication
Tomas Vondra <tomas.vondra@enterprisedb.com>
On 12/14/21 17:43, Alvaro Herrera wrote: > On 2021-Dec-13, Alvaro Herrera wrote: > >> I think this means we need a new OBJECT_PUBLICATION_REL_COLUMN value in >> the ObjectType (paralelling OBJECT_COLUMN), and no new ObjectClass >> value. Looking now to confirm. > > After working on this a little bit more, I realized that this is a bad > idea overall. It causes lots of complications and it's just not worth > it. So I'm back at my original thought that we need to throw an ERROR > at ALTER TABLE .. DROP COLUMN time if the column is part of a > replication column filter, and suggest the user to remove the column > from the filter first and reattempt the DROP COLUMN. > > This means that we need to support changing the column list of a table > in a publication. I'm looking at implementing some form of ALTER > PUBLICATION for that. > Yeah. I think it's not clear if this should behave more like an index or a view. When an indexed column gets dropped we simply drop the index. But if you drop a column referenced by a view, we fail with an error. I think we should handle this more like a view, because publications are externally visible objects too (while indexes are pretty much just an implementation detail). But why would it be easier not to add new object type? We still need to check there is no publication referencing the column - either you do that automatically through a dependency, or you do that by custom code. Using a dependency seems better to me, but I don't know what are the complications you mentioned. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Doc: Explain about Column List feature.
- f98d07424523 16.0 landed
- 25996a82a446 15.0 landed
-
Doc: fix column list vs. replica identity rules.
- 376af686111e 16.0 landed
- ab3131880d8a 15.0 landed
-
Prohibit combining publications with different column lists.
- fd0b9dcebda7 15.0 cited
-
Fix the check to limit sync workers.
- be46985bed8a 10.21 landed
- a90de822e483 11.16 landed
- 59348fbdeb7b 12.11 landed
- 82d4a17a1750 13.7 landed
- c9dea58e2702 14.3 landed
- dd4ab6fd6528 15.0 landed
-
Wait for subscription to sync in t/031_column_list.sql
- 404f49338fef 15.0 landed
-
Move prattrs to the pg_publication_rel section in docs
- 41b00f8e601f 15.0 landed
-
Allow specifying column lists for logical replication
- 923def9a533a 15.0 landed
-
Fix row filters with multiple publications
- 5a079662256e 15.0 landed
-
Fix publish_as_relid with multiple publications
- 27fafee72d17 13.7 landed
- 677a1dc0ca0f 14.3 landed
- c91f71b9dc91 15.0 landed
-
Add some additional tests for row filters in logical replication.
- ceb57afd3ce1 15.0 cited
-
Add index on pg_publication_rel.prpubid
- 025b920a3d45 15.0 landed
-
Avoid using DefElemAction in AlterPublicationStmt
- 9623d8999603 15.0 landed
-
Small cleanups related to PUBLICATION framework code
- c9105dd3660f 15.0 landed
-
Add PublicationTable and PublicationRelInfo structs
- 0c6828fa987b 15.0 landed
-
Fix various concurrency issues in logical replication worker launching
- de4389712206 10.0 cited