Re: alter function/procedure depends on extension

On Thu, Feb 17, 2022 at 5:15 PM Bryn Llewellyn <bryn(at)yugabyte(dot)com> wrote:

>
> 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.