[Server]: Clean up functional index handling to block extension uninstall

[villagesql-adam]

Confirm whether functional indexes on custom type columns currently block extension uninstall (expected: they should prevent uninstall if active indexes depend on the extension's types). If they don't block correctly, fix the behavior.

Also think through analogous cases — other schema objects that depend on an extension that could leave the server in an inconsistent state if the extension is uninstalled without proper cleanup.

CSV ID: 225

[pyshx]

@villagesql-adam @villagestevers Mind if I take this one up?
Dictionary cache + extension lifecycle, both new to me. Best pure learning.

[pyshx]

Did an audit of remove_extension_from_victionary to find every path that could leak an extension dependency through UNINSTALL. Summarizing here for the record; PR #508 closes the one outstanding code gap.

The issue's literal ask is already satisfied today. A functional index over a custom-typed column requires the column to be that custom type, which is tracked in villagesql.custom_columns. The persistent column check blocks UNINSTALL in both open-cache and cold-cache states:

INSTALL EXTENSION vsql_complex;
CREATE TABLE t (id INT PRIMARY KEY, c COMPLEX,
                INDEX idx_func ((vsql_complex.complex_real(c))));
UNINSTALL EXTENSION vsql_complex;
-- ERROR HY000: Cannot drop extension `vsql_complex` as 1 column(s) depend on it,
--              e.g. test.t.c has type COMPLEX
FLUSH TABLES;
UNINSTALL EXTENSION vsql_complex;
-- Same error — persistent.

Full per-object survey

Object	Today's block path	Status
Column of custom type	villagesql.custom_columns (persistent)	Covered
SP / function parameter of custom type	villagesql.custom_sp_params (persistent)	Covered
Functional index on a custom-typed column	custom_columns on the underlying column	Covered
Generated column / CHECK / DEFAULT referencing a custom-typed column	custom_columns on the underlying column	Covered
Partitioning expression calling a VDF	Item_udf_func inherits the default check_partition_func_processor returning true — UDFs categorically banned at CREATE TABLE time	Covered (cannot be created)
Custom index (USING EXTENDED(ext.type))	None today — villagesql.custom_indexes exists but uninstall did not enumerate it	Fixed in #508
Functional index / generated column / CHECK / DEFAULT calling a deterministic VDF over only-built-in inputs	Only the in-memory use_count check — disappears once the object is closed (cold cache)	Architectural; not reachable today (every in-tree deterministic VDF requires at least one custom-type argument, so the custom_columns check already gates every reachable case)
View body referencing a VDF	None — view body stored as SQL text in mysql.views, never enumerated, not eagerly opened	Reachable today — separate follow-up needed
Trigger body referencing a VDF	Same shape as views (inferred from code)	Separate follow-up
Stored procedure body referencing a VDF	Same	Separate follow-up

View leak, empirically reproduced today

INSTALL EXTENSION vsql_complex;
CREATE VIEW v AS SELECT vsql_complex.complex_real('(1,2)') AS r;
FLUSH TABLES;
UNINSTALL EXTENSION vsql_complex;   -- succeeds, leaving a dangling VDF reference

A variant with CREATE VIEW v AS SELECT vsql_complex.complex_real(c) FROM t followed by DROP TABLE t reproduces the same leak: dropping the table clears the only custom_columns row, the view body persists in mysql.views, and uninstall succeeds.

MySQL's existing mysql.view_routine_usage doesn't help here — fill_dd_view_routines (sql/dd/dd_view.cc:443) only walks Sroutine_hash_entry::FUNCTION, which are stored functions, not UDFs/VDFs.

What still needs to happen

1. PR deny UNINSTALL EXTENSION if indexes exist #508 — custom_indexes enumeration. Mirrors the existing check_for_columns_of_extension/check_for_sp_params_of_extension pattern; RESTRICT-only.
2. Separate issue (to file) — view / trigger / SP body VDF-reference leak on UNINSTALL. Architectural: needs either a DD walk + parse at uninstall time, or a new persistent dependency table written at view/trigger/SP CREATE time (the same pattern custom_columns already follows for column-typed dependencies). Reachable today through views; trigger and SP body cases share the code structure but were not separately reproduced.

The cold-cache value-generator gap isn't worth its own ticket yet — it's architectural-only and no in-tree extension makes it reachable.

[villagestevers]

custom indexes is not fully implemented yet, so no surprise there. For views and triggers, etc. I think we should figure out what happens for UDFs that go away. I think we had decided these would refer to the VDF and then error out, just like UDFs would. We should add tests for this behavior, if they are not there already. If that's the case, then it is ok to uninstall as is.