Re: bogus: logical replication rows/cols combinations

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: bogus: logical replication rows/cols combinations
Date: 2022-04-28 12:13:25
Message-ID: ab1e4808-7cce-0905-377a-a174bce091ea@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 27.04.22 11:53, Alvaro Herrera wrote:
> Now, another possibility is to say "naah, this is too hard", or even
> "naah, there's no time to write all that for this release". That might
> be okay, but in that case let's add an implementation restriction to
> ensure that we don't paint ourselves in a corner regarding what is
> reasonable behavior. For example, an easy restriction might be: if a
> table is in multiple publications with mismatching row filters/column
> lists, then a subscriber is not allowed to subscribe to both
> publications. (Maybe this restriction isn't exactly what we need so
> that it actually implements what we need, not sure). Then, if/when in
> the future we implement this correctly, we can lift the restriction.

My feeling is also that we should prohibit the combinations that we
cannot make work correctly.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2022-04-28 12:26:25 Re: bogus: logical replication rows/cols combinations
Previous Message vignesh C 2022-04-28 12:07:45 Re: Multi-Master Logical Replication