So I don't know what to believe.
Well, since the documentation supports what I was saying but the implementation effectively supports what Adrian was saying this confusion isn't surprising. The status quo is inconsistent and needs to be changed somehow. I claim the documentation is correct and the RESTRICT clause non-adherence is a bug to be fixed (arguable whether to back-patch).
However, the notion seems to me to be back to front. I'd expect that an extension would by definition, depend on its member objects rather than the other way round.
An extension neither depends on nor is dependent upon its members. The extension IS the members. Objects external to the extension can use the members of the extension. But since a function is a black box this doesn't produce a dependency. Thus a function can be explicitly made to depend on an extension to put a real relationship into the database for what was already there in fact.
I *think* that, despite his "Nevermind this", David continues to believe that "drop extension e restrict" should refuse to go ahead if there exists at least one subprogram that has been defined, using "alter function/procedure" to depend on "e".
Yes. The "nevermind this" was strictly for my original proposal to update the ALTER FUNCTION documentation wording. Nothing else.
Fair enough. But if you generalize this to a requirements statement across more scenarios, then you can't get the behavior that Álvaro says is desirable. I did this test:1. created table t.2. created procedure abort(text) that does "assert false" and uses the actual input as the message.3. created a trigger function to be called from a trigger that fires "after update for each row". If it detects any change, then it calls "abort()".4. created the trigger on "t".Then (and without dropping the tigger function "cascade") I attempted to drop the "abort()" procedure with no "cascade". This silently succeeded. Then I tried to update a row, This causer the "XX000" error "cache lookup failed for function 1499654". In other words, Álvaro's implied requirements statement cannot be met in this scenario. (But, at least, the insert attempt did fail.)
Right, the trigger function itself is a black box - the fact that you got a "cache lookup" failure instead of a "function not found" failure is largely immaterial (but may be a bug in its own right). Avoiding this situation when dealing with extensions is exactly why a function can be declared to depend on an extension. If the abort() function were part of an extension and the dependency from the trigger function to the extension were installed then the attempt to drop the extension would either fail (restrict) or the trigger function you created would be deleted (cascade). You would not be left with a trigger function referencing an extension function that no longer exists.
This simply is what it is. PG users have no choice but to understand both kinds of dependency model. But given this, I still see little value in using the "alter function/procedure depends on extension" to change a dynamic dependency into a static dependency because it brings just one nugget of static dependency within a larger universe where the dynamic dependencies paradigm reigns.
Maybe, but the behavior does exist but is bugged in its current state. Whether it is advisable for users to use this feature is immaterial, the bug needs to be fixed so that is works as documented for those that choose to do so.
David J.
