Re: why can't a table be part of the same publication as its schema
От | Robert Haas |
---|---|
Тема | Re: why can't a table be part of the same publication as its schema |
Дата | |
Msg-id | CA+Tgmoaf=vvTZug0nT8ihti1jvLXnvSaRj1osLjVjmKwQTjfDg@mail.gmail.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
Re: why can't a table be part of the same publication as its schema |
Список | pgsql-hackers |
On Fri, Sep 9, 2022 at 10:29 AM houzj.fnst@fujitsu.com <houzj.fnst@fujitsu.com> wrote: > IIRC, the feature currently works almost the same as you described. It doesn't > create entry for tables that are published via its schema level, it only record > the published schema and check which tables are part of it. Oh, well if that's the case, that is great news. But then I don't understand Amit's comment from before: > Yes, because otherwise, there was confusion while dropping the objects > from publication. Consider in the above case, if we would have allowed > it and then the user performs ALTER PUBLICATION p1 DROP ALL TABLES IN > SCHEMA s1, then (a) shall we remove both schema s1 and a table that is > separately added (s1.t1) from that schema, or (b) just remove schema > s1? I believe that (b) is the correct behavior, so I assumed that this issue must be some difficulty in implementing it, like a funny catalog representation. Things might be clearer if we'd made the syntax "ALTER PUBLICATION p1 { ADD | DROP } { TABLE | SCHEMA } name". I don't understand why we used this ALL TABLES IN SCHEMA language. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: