On Tue, Jul 5, 2022 at 08:12:09PM -0400, Tom Lane wrote:
> "David G. Johnston" <david.g.johnston@gmail.com> writes:
>
> + A function that's marked as dependent on an extension is dropped when the
> + extension is dropped, even if cascade is not specified.
> + dependency checking in restrict mode <xref linkend="sql-dropextension"/>.
> + A function can depend upon multiple extensions, and will be dropped when
> + any one of those extensions is dropped.
>
> Third line here seems like a copy/paste mistake? Also I'd tend
> to mark up the keyword as <literal>CASCADE</literal>.
>
> + This form marks the procedure as dependent on the extension, or no longer
> + dependent on that extension if <literal>NO</literal> is specified.
>
> The/that inconsistency ... choose one. Or actually, the "an ... the"
> combination you used elsewhere doesn't grate on the ear either.
>
> + For each extension, refuse to drop anything if any objects (other than the
> + extensions listed) depend on it. However, its own member objects, and routines
> + that are explicitly dependent on this extension, are skipped.
> + This is the default.
>
> "skipped" seems like a horrible choice of word; it could easily be read as
> "they don't get dropped". I am not convinced that mentioning the member
> objects here is an improvement either. In the first sentence you are
> treating each extension as a monolithic object; why not in the second?
I created a modified patch based on this feedback; patch attached. I
rewrote the last change.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Indecision is a decision. Inaction is an action. Mark Batterson