On Tue, May 9, 2017 at 2:07 PM, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > On 5/8/17 23:23, Peter Eisentraut wrote: >> The way this uses RESTRICT and CASCADE appears to be backwards from its >> usual meaning. Normally, CASCADE when dropping an object that is still >> used by others will cause those other objects to be dropped. The >> equivalent here would be DROP REPLICATION SLOT + CASCADE would drop the >> subscription. >> >> What we want to simulate instead is an "auto" dependency of the slot on >> the subscription. So you can drop the slot separately (subject to other >> restrictions), and it is dropped automatically when the subscription is >> dropped. To avoid that, you can disassociate the slot from the >> subscription, which you have implemented. >> >> I think we can therefore do without RESTRICT/CASCADE here. If a slot is >> associated with the subscription, it should be there when we drop the >> subscription. Otherwise, the user has to disassociate the slot and take >> care of it manually. So just keep the "cascade" behavior. >> >> Similarly, I wouldn't check first whether the slot exists. If the >> subscription is associated with the slot, it should be there. > > Here is your patch amended for that. >
I think we should change tab-completion support for that as well. diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c index 183fc37..046fdd5 100644 --- a/src/bin/psql/tab-complete.c +++ b/src/bin/psql/tab-complete.c @@ -2684,7 +2684,7 @@ psql_completion(const char *text, int start, int end) /* DROP SUBSCRIPTION */ else if (Matches3("DROP", "SUBSCRIPTION", MatchAny)) - COMPLETE_WITH_LIST2("DROP SLOT", "NODROP SLOT"); + COMPLETE_WITH_LIST2("CASCADE", "RESTRICT"); /* EXECUTE */ else if (Matches1("EXECUTE")) Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers