From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
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:26:25 |
Message-ID: | 39077967-c327-eddb-ac4b-7d64117944fb@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 27.04.22 12:33, Amit Kapila wrote:
> Currently, when the subscription has multiple publications, we combine
> the objects, and actions of those publications. It happens for
> 'publish_via_partition_root', publication actions, tables, column
> lists, or row filters. I think the whole design works on this idea
> even the initial table sync. I think it might need a major change
> (which I am not sure about at this stage) if we want to make the
> initial sync also behave similar to what you are proposing.
If one publication says "publish if insert" and another publication says
"publish if update", then the combination of that is clearly "publish if
insert or update". Similarly, if one publication says "WHERE (foo)" and
one says "WHERE (bar)", then the combination is "WHERE (foo OR bar)".
But if one publication says "publish columns a and b if condition-X" and
another publication says "publish columns a and c if not-condition-X",
then the combination is clearly *not* "publish columns a, b, c if true".
That is not logical, in the literal sense of that word.
I wonder how we handle the combination of
pub1: publish=insert WHERE (foo)
pub2: publish=update WHERE (bar)
I think it would be incorrect if the combination is
pub1, pub2: publish=insert,update WHERE (foo OR bar).
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2022-04-28 13:49:15 | Re: json_query - redundant result |
Previous Message | Peter Eisentraut | 2022-04-28 12:13:25 | Re: bogus: logical replication rows/cols combinations |