On 2021-Dec-14, Tomas Vondra wrote: > 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).
I agree -- I think it's more like a view than like an index. (The original proposal was that if you dropped a column that was part of the column list of a relation in a publication, the entire relation is dropped from the view, but that doesn't seem very friendly behavior -- you break the replication stream immediately if you do that, and the only way to fix it is to send a fresh copy of the remaining subset of columns.) > 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. The problem is that we need a way to represent the object "column of a table in a publication". I found myself adding a lot of additional code to support OBJECT_PUBLICATION_REL_COLUMN and that seemed like too much. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/