Re: Column Filtering in Logical Replication

On 12/14/21 20:35, Alvaro Herrera wrote:
> 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.)
> 

Right, that's my reasoning too.

>> 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.
> 

My experience with dependencies is pretty limited, but can't we simply 
make a dependency between the whole publication and the column?

regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company