Feedback-ID: i131946ab:Fastmail
Message-ID: <b2ffd236-fefd-f8f8-05a0-dc603e5a2bae@enterprisedb.com>
Date: Wed, 14 Sep 2022 21:36:37 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.2.2
Subject: Re: why can't a table be part of the same publication as its schema
Content-Language: en-US
To: "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>,
 vignesh C <vignesh21@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
References: <2729c9e2-9aac-8cda-f2f4-34f2bcc18f4e@enterprisedb.com>
 <CAA4eK1KDX2S1bct1-y_dXpV3VpYU5CotU9MN57uzPOSWEararQ@mail.gmail.com>
 <37271.1662704091@sss.pgh.pa.us>
 <CAA4eK1JPPQ1j=m15QCvU2Yfdq70yVhZejpvPi27GaVD4urWAgA@mail.gmail.com>
 <CA+TgmoZOE9uDzjiLBi_8yqVcqrfMYfvp02DLF1fFzOR9Zp4txg@mail.gmail.com>
 <OS0PR01MB5716FA725E51EF7F130E59AC94439@OS0PR01MB5716.jpnprd01.prod.outlook.com>
 <CA+Tgmoaf=vvTZug0nT8ihti1jvLXnvSaRj1osLjVjmKwQTjfDg@mail.gmail.com>
 <CAA4eK1+V25w5JO=i++W=Mzyf3i8d3++Y2JvuStqSLMk6QMUyeg@mail.gmail.com>
 <CALDaNm0Abj_Ui3apZWuuMLtvqic6eoQCn3EgZzcxNAfz5grDUw@mail.gmail.com>
 <OS0PR01MB571613363874441516C5BBCC94469@OS0PR01MB5716.jpnprd01.prod.outlook.com>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
In-Reply-To: 
 <OS0PR01MB571613363874441516C5BBCC94469@OS0PR01MB5716.jpnprd01.prod.outlook.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/b2ffd236-fefd-f8f8-05a0-dc603e5a2bae%40enterprisedb.com>
Precedence: bulk

On 14.09.22 07:10, houzj.fnst@fujitsu.com wrote:
> After applying the patch, we support adding a table with column list along with
> the table's schema[1], and it will directly apply the column list in the
> logical replication after applying the patch.
> 
> [1]--
> CREATE PUBLICATION pub FOR TABLE public.test(a), FOR ALL TABLES IN SCHEMA public;
> -----
> 
> If from the point of view of consistency, for column list, we could report an
> ERROR because we currently don't allow using different column lists for a
> table. Maybe an ERROR like:
> 
> "ERROR: cannot use column for table x when the table's schema is also in the publication"
> 
> But if we want to report an ERROR for column list in above case. We might need
> to restrict the ALTER TABLE SET SCHEMA as well because user could move a table
> which is published with column list to a schema that is also published in the
> publication, so we might need to add some similar check(which is removed in
> Vignesh's patch) to tablecmd.c to disallow this case.
> 
> Another option could be just ingore the column list if table's schema is also
> part of publication. But it seems slightly inconsistent with the rule that we
> disallow using different column list for a table.

Ignoring things doesn't seem like a good idea.

A solution might be to disallow adding any schemas to a publication if 
column lists on a table are specified.