Re: Proposal: Conflict log history table for Logical Replication

Currently we allow inheritance from CLT. I see 2 side-effects

a) Queries on the CLT will always include rows from inherited tables.
Whether this is desirable or not is subjective, but it can lead to
unexpected results for DBAs querying the CLT directly.

CREATE TABLE public.my_custom_extended_log() INHERITS
(pg_conflict.pg_conflict_log_16392);
INSERT INTO public.my_custom_extended_log (relid, schemaname, relname,
conflict_type) VALUES (99999, 'public', 'fake_table',
'forged_conflict_type');

postgres=# SELECT count(*), conflict_type FROM
pg_conflict.pg_conflict_log_16392 GROUP BY conflict_type;
count | conflict_type
-------+----------------------
5 | insert_exists
2 | forged_conflict_type

b)
DROP SUBSCRIPTION may unintentionally drop inherited tables.

When a subscription is dropped, the associated CLT is removed
internally using DROP-CASCADE. As a result, any user table inheriting
from the CLT would also be dropped, causing the user to lose any data
stored in those inherited tables.

postgres=# DROP SUBSCRIPTION sub1;
NOTICE: drop cascades to table my_custom_extended_log
NOTICE: dropped conflict log table
"pg_conflict.pg_conflict_log_16392" for subscription "sub1"
NOTICE: dropped replication slot "sub1" on publisher

OTOH, regular tables provide an opportunity for the user to review
dependencies and decide how to proceed:

postgres=# create table tab1( i int);
CREATE TABLE

postgres=# create table tab_i() inherits (tab1);
CREATE TABLE

postgres=# drop table tab1;
ERROR: cannot drop table tab1 because other objects depend on it
DETAIL: table tab_i depends on table tab1
HINT: Use DROP ... CASCADE to drop the dependent objects too.

~~

I previously thought inheriting from CLT should be acceptable as that
is purely the user's decision to create a child table for its own
purpose, but upon rethinking, I believe it should be blocked.
Thoughts?

thanks
Shveta