On 2/17/22 08:52, Bryn Llewellyn wrote:
> **Briefly**
>
> *qu. 2.* Why does "drop extension restrict" quietly succeed—having the
> effect of cascade-dropping any subprogram that you've altered to depend
> on the extension in question? This is at odds with the documented
> meaning of "restrict".
But not the ALTER FUNCTION docs:
https://www.postgresql.org/docs/current/sql-alterfunction.html
"DEPENDS ON EXTENSION extension_name
NO DEPENDS ON EXTENSION extension_name
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.
"
And from DROP EXTENSION
https://www.postgresql.org/docs/current/sql-dropextension.html
"RESTRICT
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.
"
The DEPENDS ON EXTENSION turns a function into a member object. The
'...any objects depend on it....' is shown in the EXAMPLES:
"To remove the extension hstore from the current database:
DROP EXTENSION hstore;
This command will fail if any of hstore's objects are in use in the
database, for example if any tables have columns of the hstore type. Add
the CASCADE option to forcibly remove those dependent objects as well.
"
>
> *qu. 3.* I established by experiment that you can repeat "alter
>
--
Adrian Klaver
adrian.klaver@aklaver.com