Re: why can't a table be part of the same publication as its schema

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: why can't a table be part of the same publication as its schema
Дата
Msg-id 20220920140119.mct473wrvvrikrg2@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: why can't a table be part of the same publication as its schema  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Список pgsql-hackers
On 2022-Sep-13, Kyotaro Horiguchi wrote:

> At Mon, 12 Sep 2022 04:26:48 +0000, "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com> wrote in 

> > I feel we'd better compare the syntax with the existing publication command:
> > FOR ALL TABLES. If you create a publication FOR ALL TABLES, it means publishing
> > all the tables in the database *including* tables created in the future. I
> > think both the syntax and meaning of ALL TABLES IN SCHEMA are consistent with
> > the existing FOR ALL TABLES.
> 
> IMHO, I feel closer to Robert. "ALL TABLES IN SCHEMA" sounds like the
> concrete tables at the time of invocation.  While I agree that it is
> not directly comparable to GRANT, 

What if we remove the ALL keyword from there?  That would leave us with
"FOR TABLES IN SCHEMA", which seems to better convey that it doesn't
restrict to current tables in there.


> but if I see "ALTER PUBLICATION p1 ADD SCHEMA s1", I automatically
> translate that into "all tables in the schema s1 at the time of using
> this publication".

... but that translation is wrong if replication supports other kinds of
objects, as it inevitably will in the near future.  Clearly the fact
that we spell out TABLES there is important.  When we add support for
sequences, we could have combinations

ADD [ALL] TABLES IN SCHEMA s
ADD [ALL] SEQUENCES IN SCHEMA s
ADD [ALL] TABLES AND SEQUENCES IN SCHEMA s

and at that point, the unadorned ADD SCHEMA one will become ambiguous.

> At least, it would cause less confusion when it were "ALT PUB p1 DROP
> SCEMA s1" aginst "DROP ALL TABLES IN SCHEMA s1".

I'm not sure what you mean here.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"En las profundidades de nuestro inconsciente hay una obsesiva necesidad
de un universo lógico y coherente. Pero el universo real se halla siempre
un paso más allá de la lógica" (Irulan)



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

Предыдущее
От: Sergey Shinderuk
Дата:
Сообщение: Re: On login trigger: take three
Следующее
От: Daniel Gustafsson
Дата:
Сообщение: Re: On login trigger: take three