Re: pg_get_publication_tables() output duplicate relid

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: pg_get_publication_tables() output duplicate relid
Дата
Msg-id CAA4eK1LT+Wf87tML9dKDu_AZMaMdYUC59XcA+ELr1yUbkot4tQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_get_publication_tables() output duplicate relid  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: pg_get_publication_tables() output duplicate relid  (Amit Langote <amitlangote09@gmail.com>)
Список pgsql-hackers
On Mon, Nov 15, 2021 at 7:12 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> > 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?
>

I think it could provide flexibility to users to later change
"publish_via_partition_root" option. Because when that option is
false, we use individual partitions schema to send changes and when it
is true, we use root table's schema to send changes. Added Amit L. to
know if he has any thoughts on this matter as he was the author of
this work?

-- 
With Regards,
Amit Kapila.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Daniel Gustafsson
Дата:
Сообщение: Re: CREATE PUBLICATION should "See Also" CREATE SUBSCRIPTION
Следующее
От: Daniel Gustafsson
Дата:
Сообщение: Re: Allow CURRENT_ROLE in GRANTED BY