Re: why can't a table be part of the same publication as its schema
От | Peter Eisentraut |
---|---|
Тема | Re: why can't a table be part of the same publication as its schema |
Дата | |
Msg-id | b2ffd236-fefd-f8f8-05a0-dc603e5a2bae@enterprisedb.com обсуждение исходный текст |
Ответ на | RE: why can't a table be part of the same publication as its schema ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>) |
Ответы |
RE: why can't a table be part of the same publication as its schema
|
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: