Thread: doc: Clarify Routines and Extension Membership
Hi.
Reposting this on its own thread.
Per discussion on -general the documentation for the
ALTER ROUTINE ... DEPENDS ON EXTENSION and DROP EXTENSION doesn't
clearly indicate that these dependent routines are treated in a
similar manner to the extension's owned objects when it comes to
using RESTRICT mode drop: namely their presence doesn't force
the drop command to abort. Clear that up.
ALTER ROUTINE ... DEPENDS ON EXTENSION and DROP EXTENSION doesn't
clearly indicate that these dependent routines are treated in a
similar manner to the extension's owned objects when it comes to
using RESTRICT mode drop: namely their presence doesn't force
the drop command to abort. Clear that up.
David J.
Attachment
"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?
regards, tom lane
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
Attachment
On Fri, Jul 8, 2022 at 10:55:55PM -0400, Bruce Momjian wrote: > > 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. Patch applied to PG 13 and later, where extension dependency was added. Thank you for the patch. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Indecision is a decision. Inaction is an action. Mark Batterson
On Thu, Jul 14, 2022 at 2:41 PM Bruce Momjian <bruce@momjian.us> wrote:
On Fri, Jul 8, 2022 at 10:55:55PM -0400, Bruce Momjian wrote:
> > 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.
Patch applied to PG 13 and later, where extension dependency was added.
Thank you for the patch.
Thank you and apologies for being quiet here and on a few of the other threads. I've been on vacation and flagged as ToDo some of the non-simple feedback items that have come this way.
The change to restrict and description in drop extension needs to be fixed up (the other pages look good).
"This option prevents the specified extensions from being dropped if there exists non-extension-member objects that depends on any the extensions. This is the default."
At minimum: "...that depend on any of the extensions."
I did just now confirm that if any of the named extensions failed to be dropped the entire command fails. There is no partial success mode.
I'd like to avoid non-extension-member, and one of the main points is that the routine dependency is member-like, not actual membership. Hence the separate wording.
I thus propose to replace the drop extension / restrict paragraph and replace it with the following:
"This option prevents the specified extensions from being dropped if other objects - besides these extensions, their members, and their explicitly dependent routines - depend on them. This is the default."
Also, I'm thinking to change, on the same page (description):
"Dropping an extension causes its component objects,"
to be:
"Dropping an extension causes its member objects,"
I'm not sure why I originally chose component over member...
David J.
On Thu, Jul 14, 2022 at 06:27:17PM -0700, David G. Johnston wrote: > Thank you and apologies for being quiet here and on a few of the other threads. > I've been on vacation and flagged as ToDo some of the non-simple feedback items > that have come this way. No need to worry --- we will incorporate your suggestions whenever you can supply them. I know you waited months for these to be addressed. > The change to restrict and description in drop extension needs to be fixed up > (the other pages look good). > > "This option prevents the specified extensions from being dropped if there > exists non-extension-member objects that depends on any the extensions. This is > the default." > > At minimum: "...that depend on any of the extensions." Agreed. > I did just now confirm that if any of the named extensions failed to be dropped > the entire command fails. There is no partial success mode. > > I'd like to avoid non-extension-member, and one of the main points is that the > routine dependency is member-like, not actual membership. Hence the separate > wording. Okay. > I thus propose to replace the drop extension / restrict paragraph and replace > it with the following: > > "This option prevents the specified extensions from being dropped if other > objects - besides these extensions, their members, and their explicitly > dependent routines - depend on them. This is the default." Good. > Also, I'm thinking to change, on the same page (description): > > "Dropping an extension causes its component objects," > > to be: > > "Dropping an extension causes its member objects," > > I'm not sure why I originally chose component over member... All done, in the attached patch. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Indecision is a decision. Inaction is an action. Mark Batterson
Attachment
On Mon, Jul 18, 2022 at 04:40:15PM -0400, Bruce Momjian wrote: > > Also, I'm thinking to change, on the same page (description): > > > > "Dropping an extension causes its component objects," > > > > to be: > > > > "Dropping an extension causes its member objects," > > > > I'm not sure why I originally chose component over member... > > All done, in the attached patch. Patch applied through PG 13, where extension dependency tracking was added. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Indecision is a decision. Inaction is an action. Mark Batterson