MySQL Bugs: #117850: Expose more component information to SQL than currently provided

Bug #117850	Expose more component information to SQL than currently provided
Submitted:	2 Apr 6:58	Modified:	2 Apr 8:45
Reporter:	Simon Mudd (OCA)	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Server: Information schema	Severity:	S4 (Feature request)
Version:	8.0, 8.4, 9.x	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	component, plugins, upgrades, visibility

Description:
I have been building MySQL plugins for internal usage for some time.
Oracle now recommends using components as an alternative as the interface provided is richer. That's good

Plugin and component interfaces seem to be pretty stable and may be the same over multiple versions. This means it's not always necessary to rebuild a plugin or component but a previously built one can be used. When upgrading however, if you do not rebuild every time, or if an improvement or bug fix may be applicable you need to know the version used (from the SQL prompt of the server) to verify if the installed vs wanted version is running.

With plugins you can do this. The access to plugin information is somewhat confusing as there are 3 ways to access information about plugins: SHOW PLUGINS, SELECT * FROM INFORMATION_SCHEMA.PLUGINS and SELECT * FROM mysql.plugin. (The information is not consistent).

With components as far as I can see there's only the option SELECT * FROM mysql.component and the few columns provided are minimal at least compared to plugin provided information on author, copyright, version, description and so on.

I looked briefly at the docs and there's little information about this.

If you want to make it easy to plugin new things into MySQL and from that make it easier to extend it or allows others to extend it in new ways this new component infrastructure sounds promising. However, to do that you need to ensure that the infrastructure and documentation is in place to make managing this easier.

If I want to manage a component

How to repeat:
Read up documentation on plugins, components.

- You'll see information on components is rather limited to plugins.
- You'll see the plugin interface is somewhat inconsistent which is very visible if you try to dynamically load or unload plugins.
- There's no visible reference to the fact that Oracle wants people to move to the component infrastructure from the existing plugin infrastructure (which is fine and probably will be more stable) so perhaps documentation should mention this so people can look at what is required to implement such changes.

Suggested fix:
I would suggest that if not present more information about the component is exposed through the SQL prompt for the reasons mentioned:

e.g.
- component name
- version of the component (also what format should it take and how to expose it?)
- version of MySQL the component was built on/against, would normally be expected to be the same as the MySQL server but might be different.
- author (I believe already provided?)
- copyright (I believe already provided?)
- license (I believe already provided?)
- description
- required dependencies
- current users of the component (this would be dynamic)
- it might also be a plugin, component or UDF?
- other fields I may have missed.

In a similar manner for UDFs exposing them if not done already would be useful.

Ensure that documentation is enhanced to provide examples of how to load / unload the component (already present), verify the component information (already provided but the current 2 fields are too little) and then have a pointer to developer documentation on how to build a component. References to Fred's blog series on building a component may also be interesting though it may need updating to be valid for 8.4 or 9.X.

We don't have much time to do this if you want 9.7 to be LTS and will not make incompatible changes in the server before then. I am assuming that backporting this to 8.4 may not happen though it might be nice. 8.0 can be forgotten as it goes EOL in 1 year.

component information provided by MySQL 8.4 is minimal:

mysql> SELECT * FROM mysql.component;
+--------------+--------------------+------------------------------------+
| component_id | component_group_id | component_urn                      |
+--------------+--------------------+------------------------------------+
|            1 |                  1 | file://component_validate_password |
|            2 |                  2 | file://component_log_sink_json     |
+--------------+--------------------+------------------------------------+

A different box I use shows this:

+--------------+--------------------+-------------------------------------+
| component_id | component_group_id | component_urn                       |
+--------------+--------------------+-------------------------------------+
|            1 |                  1 | file://component_log_filter_dragnet |
+--------------+--------------------+-------------------------------------+

Again rather basic.

Also compare this with I_S.PLUGINS (8.4.4):

show create table information_schema.plugins\G
*************************** 1. row ***************************
       Table: PLUGINS
Create Table: CREATE TEMPORARY TABLE `PLUGINS` (
  `PLUGIN_NAME` varchar(64) NOT NULL DEFAULT '',
  `PLUGIN_VERSION` varchar(20) NOT NULL DEFAULT '',
  `PLUGIN_STATUS` varchar(10) NOT NULL DEFAULT '',
  `PLUGIN_TYPE` varchar(80) NOT NULL DEFAULT '',
  `PLUGIN_TYPE_VERSION` varchar(20) NOT NULL DEFAULT '',
  `PLUGIN_LIBRARY` varchar(64) DEFAULT NULL,
  `PLUGIN_LIBRARY_VERSION` varchar(20) DEFAULT NULL,
  `PLUGIN_AUTHOR` varchar(64) DEFAULT NULL,
  `PLUGIN_DESCRIPTION` longtext,
  `PLUGIN_LICENSE` varchar(80) DEFAULT NULL,
  `LOAD_OPTION` varchar(64) NOT NULL DEFAULT ''
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3  <====== time to move to utf8mb4?

Hello Simon,

Thank you for the feature request!

regards,
Umesh

Note: I see the category has been changed to MySQL Server: Information schema.
That may be correct but performance_schema may be better as if we want to see live dependency references between components etc then information_schema may not be appropriate. Either way that's a detail, it making the information available that's important and useful.