Re: logical replication syntax (was DROP SUBSCRIPTION, query cancellations and slot handling)

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Thu, Apr 20, 2017 at 7:46 AM, Petr Jelinek
>> <petr(dot)jelinek(at)2ndquadrant(dot)com> wrote:
>>> DROP SUBSCRIPTION mysub NODROP SLOT;

>> I'm pretty uninspired by this choice of syntax.

Actually, this command has got much worse problems than whether you like
the spelling of its option: it shouldn't have an option in the first
place. I put it to you as an inviolable rule that no object DROP command
should ever have any options other than RESTRICT/CASCADE and IF EXISTS.
If it does, then you don't know what to do when the object is recursed
to by a cascaded drop.

It's possible that we could allow exceptions to this rule for object types
that can never have any dependencies. But a subscription doesn't qualify
--- it's got an owner, so DROP OWNED BY already poses this problem. Looks
to me like it's got a dependency on a database, too. (BTW, if
subscriptions are per-database, why is pg_subscription a shared catalog?
There were some pretty schizophrenic decisions here.)

So ISTM we need to get rid of the above-depicted syntax. We could instead
have what-to-do-with-the-slot as a property of the subscription,
established at CREATE SUBSCRIPTION and possibly changed later by ALTER
SUBSCRIPTION. Not quite sure what to call the option, maybe something
based on the concept of the subscription "owning" the slot.

I think this is a must-fix issue, and will put it on the open items
list.

regards, tom lane