Metadata versioning of plugin tables

[mrotteveel]

Currently, structural changes to tables and views created by plugins are not properly tracked in Firebird. Meaning that when upgrading from one version to another, those tables or views might be outdated from the version that the plugin would create if it were initialized anew.

Firebird should provide a way for a plugin to record its current metadata version in a system table (shared by all plugins), and when a plugin is loaded, a plugin should check the metadata version and upgrade if needed (and maybe produce an error if its own metadata version is lower).

For example, between Firebird 3.0 and Firebird 4.0 the PLG$SRP_VIEW was changed, but this was not recorded in the release notes, nor was an upgrade script included, meaning that people who upgraded their security3.fdb by backup and restore have the wrong definition of that view.

[mrotteveel]

Alternatively, on restore gbak could iterate over the plugins listed in that metadata versioning table and ask each plugin to perform the upgrade. That way you avoid the overhead while loading the plugin.

[asfernandes]

If plugin created metadata automatically, it should upgrade automatically.

Engine don't need to offer any functionality for that.

Plugin can inspect it's metadata and do the upgrade.

[AlexBekhtin]

The latest Profiler case. I created the DB in the intermediate builds. Update FB version to release. And when i call execute procedure rdb$profiler.finish_session(true); nothing happened. The profiling tables were empty and there was no error. I deleted the tables, views, generators and role. At the first call all objects were recreated with a new structure and everything worked correctly.

There are two questions:

• The rdb$profiler plugin does not generate an error when there is an explicit error in executing a write to the summary tables
• At what point in time should the plugin bring the tables to the actual structure? (automatically, at B/R, when calling a special function of the plugin,...)