Re: [WIP] CREATE SUBSCRIPTION with FOR TABLES clause (table filter)
От | Evgeniy Efimkin |
---|---|
Тема | Re: [WIP] CREATE SUBSCRIPTION with FOR TABLES clause (table filter) |
Дата | |
Msg-id | 259931543423305@sas2-76706d252d16.qloud-c.yandex.net обсуждение исходный текст |
Ответ на | Re: [WIP] CREATE SUBSCRIPTION with FOR TABLES clause (table filter) (Evgeniy Efimkin <efimkin@yandex-team.ru>) |
Ответы |
Re: [WIP] CREATE SUBSCRIPTION with FOR TABLES clause (table filter)
(Andrey Borodin <x4mmm@yandex-team.ru>)
|
Список | pgsql-hackers |
Hello! I wrote some tests(it's just 01_rep_changes.pl but for non superuser) and fix `DROP TABLE` from subscription. Now old andnew tests pass. 22.11.2018, 16:23, "Evgeniy Efimkin" <efimkin@yandex-team.ru>: > Hello! > New draft attached with filtering table in subscription (ADD/DROP) and allow non-superusers use` CREATE SUBSCRIPTION` forown tables. > > 14.11.2018, 18:10, "Evgeniy Efimkin" <efimkin@yandex-team.ru>: >> Hello! >> I started work on patch (draft attached). Draft has changes related only to `CREATE SUBSCRIPTION`. >> I also introduce a new status (DEFFERED) for tables in `FOR TABLE` clause (but not in publication). >> New column in pg_subscription (suballtables) will be used in `REFRESH` clause >> >> 09.11.2018, 15:24, "Evgeniy Efimkin" <efimkin@yandex-team.ru>: >>> Hi! >>> In order to support create subscription from non-superuser, we need to make it possible to choose tables on the subscriberside: >>> 1. add `FOR TABLE` clause in `CREATE SUBSCRIPTION`: >>> ``` >>> CREATE SUBSCRIPTION subscription_name >>> CONNECTION 'conninfo' >>> PUBLICATION publication_name [, ...] >>> [ FOR TABLE [ ONLY ] table_name [ * ] [, ...]| FOR ALL TABLES ] >>> [ WITH ( subscription_parameter [= value] [, ... ] ) ] >>> ``` >>> ... where `FOR ALL TABLES` is only allowed for superuser. >>> and table list in `FOR TABLES` clause will be stored in pg_subscription_rel table (maybe another place?) >>> >>> 2. Each subscription should have "all tables" attribute. >>> For example via a new column in pg_subscription "suballtables". >>> >>> 3. Add `ALTER SUBSCRIPTION (ADD TABLE | DROP TABLE)`: >>> ``` >>> ALTER SUBSCRIPTION subscription_name ADD TABLE [ ONLY ] table_name [WITH copy_data]; >>> ALTER SUBSCRIPTION subscription_name DROP TABLE [ ONLY ] table_name; >>> ``` >>> 4. On `ALTER SUBSCRIPTION <name> REFRESH PUBLICATION` should check if table owner equals subscription owner. Thecheck is ommited if subscription owner is superuser. >>> 5. If superuser calls `ALTER SUBSCRIPTION REFRESH PUBLICATION` on subscription with table list and non-superuserowner, we should filter tables which owner is not subscription's owner or maybe we need to raise error? >>> >>> What do you think about it? Any objections? >>> >>> 07.11.2018, 00:52, "Stephen Frost" <sfrost@snowman.net>: >>>> Greetings, >>>> >>>> * Evgeniy Efimkin (efimkin@yandex-team.ru) wrote: >>>>> As a first step I suggest we allow CREATE SUBSCRIPTION for table owner only. >>>> >>>> That's a nice idea but seems like we would want to have a way to filter >>>> what tables a subscription follows then..? Just failing if the >>>> publication publishes tables that we don't have access to or are not the >>>> owner of seems like a poor solution.. >>>> >>>> Thanks! >>>> >>>> Stephen >>> >>> -------- >>> Ефимкин Евгений >> >> -------- >> Ефимкин Евгений > > -------- > Ефимкин Евгений -------- Ефимкин Евгений
Вложения
В списке pgsql-hackers по дате отправления:
Следующее
От: Mark DilgerДата:
Сообщение: Re: "SELECT ... FROM DUAL" is not quite as silly as it appears