Re: bogus: logical replication rows/cols combinations - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: bogus: logical replication rows/cols combinations
Date
Msg-id 6cb47e40-14d4-d29b-d45c-d62f20c091e8@enterprisedb.com
Whole thread Raw
In response to Re: bogus: logical replication rows/cols combinations  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
List pgsql-hackers
On 03.05.22 21:40, Tomas Vondra wrote:
> So what's wrong with merging the column lists as implemented in the v2
> patch, posted a couple days ago?

Merging the column lists is ok if all other publication attributes 
match.  Otherwise, I think not.

> I don't think triggers are a suitable alternative, as it executes on the
> subscriber node. So you have to first copy the data to the remote node,
> where it gets filtered. With column filters the data gets redacted on
> the publisher.

Right, triggers are not currently a solution.  But you could imagine a 
redaction filter system that runs on the publisher that modifies rows 
before they are sent out.



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [PATCH] Log details for client certificate failures
Next
From: Tom Lane
Date:
Subject: Re: Add a new function and a document page to get/show all the server hooks