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

On Tue, May 02, 2017 at 09:10:52AM -0400, Tom Lane wrote:
> 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.

[Action required within three days. This is a generic notification.]

The above-described topic is currently a PostgreSQL 10 open item. Peter,
since you committed the patch believed to have created it, you own this open
item. If some other commit is more relevant or if this does not belong as a
v10 open item, please let us know. Otherwise, please observe the policy on
open item ownership[1] and send a status update within three calendar days of
this message. Include a date for your subsequent status update. Testers may
discover new open items at any time, and I want to plan to get them all fixed
well in advance of shipping v10. Consequently, I will appreciate your efforts
toward speedy resolution. Thanks.

[1] https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com