RE: Added schema level support for publication. - Mailing list pgsql-hackers

From tanghy.fnst@fujitsu.com
Subject RE: Added schema level support for publication.
Date
Msg-id OS0PR01MB6113FBA8BE901B8D8E96B859FBA89@OS0PR01MB6113.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Added schema level support for publication.  (vignesh C <vignesh21@gmail.com>)
Responses Re: Added schema level support for publication.
List pgsql-hackers
On Monday, September 27, 2021 1:32 PM, vignesh C <vignesh21@gmail.com> wrote:

>Attached v33 patch has the preprocess_pubobj_list review comment fix
>suggested by Alvaro at [1]. The
>v33-0006-Alternate-grammar-for-ALL-TABLES-IN-SCHEMA.patch patch has
>the grammar changes as suggested by Alvaro at [1]. If we agree this is
>better, I will merge this into the 0001 patch.
>[1] - https://www.postgresql.org/message-id/202109241325.eag5g6mpvoup%40alvherre.pgsql

About the schema patch, I think a schema and a table which belongs to this schema shouldn't be specified at the same
time.
 
But what if someone uses "ALTER TABLE ... SET SCHEMA ..." after "CREATE PUBLICATION"?

For example:

create schema sch1;
create schema sch2;
create table sch2.t (a int);
create publication pub1 for all tables in schema sch1, table sch2.t; alter table sch2.t set schema sch1;

postgres=# \dRp+
                              Publication pub1
  Owner   | All tables | Inserts | Updates | Deletes | Truncates | Via root
----------+------------+---------+---------+---------+-----------+------
----------+------------+---------+---------+---------+-----------+----
 postgres | f          | t       | t       | t       | t         | f
Tables:
    "sch1.t"
Tables from schemas:
    "sch1"

Table t has been output twice.
I think this should not be supported, should we do something for this scenario?

Regards
Tang

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Gather performance analysis
Next
From: Tomas Vondra
Date:
Subject: Re: Gather performance analysis