Re: pg_get_publication_tables() output duplicate relid - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: pg_get_publication_tables() output duplicate relid
Date
Msg-id 202111151342.yvx7k7h27zcq@alvherre.pgsql
Whole thread Raw
In response to Re: pg_get_publication_tables() output duplicate relid  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses RE: pg_get_publication_tables() output duplicate relid
Re: pg_get_publication_tables() output duplicate relid
List pgsql-hackers
> On Mon, Nov 15, 2021 at 1:48 PM houzj.fnst@fujitsu.com
> <houzj.fnst@fujitsu.com> wrote:

> > create table tbl1 (a int) partition by range (a);
> > create table tbl1_part1 partition of tbl1 for values from (1) to (10);
> > create table tbl1_part2 partition of tbl1 for values from (10) to (20);
> > create publication pub for table
> > tbl1, tbl1_part1 with (publish_via_partition_root=false);

In the name of consistency, I think this situation should be an error --
I mean, if we detect that the user is trying to add both the partitioned
table *and* its partition, then all manner of things are possibly going
to go wrong in some way, so my inclination is to avoid it altogether.

Is there any reason to allow that?

If we do that, then we have to be careful with later ALTER PUBLICATION
too: adding a partition is not allowed if its partitioned table is
there, and adding a partitioned table should behave in some sensible way
if one of its partitions is there (either removing the partition at the
same time, or outright rejecting the operation.)

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: pgbench: using prepared BEGIN statement in a pipeline could cause an error
Next
From: torikoshia
Date:
Subject: Re: RFC: Logging plan of the running query