On Thu, Feb 17, 2022 at 8:54 PM Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
"David G. Johnston" <david.g.johnston@xxxxxxxxx> writes:
> On Thu, Feb 17, 2022 at 6:17 PM Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
>> There is no bug here; it's operating as designed and documented.
>> Maybe the docs need some refinement.
> We should just say that ALTER FUNCTION ALTER DEPENDS ON makes the target
> function/procedure a (transient?) member of the extension and it will be
> dropped when the extension be dropped.
It's not a member though; there's a different syntax for that
(ALTER EXTENSION name ADD member_object). The differences are
a bit subtle, but for example making the function an extension
member would change how pg_dump treats it.
So I amend my suggestions to:
"Refuse to drop the extension if any objects depend on it (other than its own member objects and other extensions listed in the same DROP command). This is the default."
...(other than its own member objects, other extensions listed in the same DROP command, and functions and procedures that have been altered to explicitly depend on those extensions). This is the default.
"This form marks the function as dependent on the extension, or no longer dependent on that extension if NO is specified. A function that's marked as dependent on an extension is automatically dropped when the extension is dropped."
...A function that's marked as dependent on an extension is ignored during the dependency crawl of a DROP EXTENSION RESTRICT (xref). It can have multiple extensions it depends on and will be dropped when any one of those extensions is dropped.
"The name of the extension that the procedure is to depend on."
Should probably match the sql-alterfunction/html wording substituting in procedure for function.
David J.
