Details
-
Task
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
None
Description
Originally, Serg and Bar decided to implement function plugins through MariaDB_FUNCTION_COLLECTION_PLUGIN, so a plugin can export multiple SQL functions at the same type.
The retionale of this solution was to avoid flooding the output of this query:
SELECT * FROM INFORMATION_SCHEMA.PLUGINS;
|
For example, we have 155 GEOMETRY related functions. Exporting all 155 function as individual plugins would add 155 entries to the query output.
After adding MariaDB_FUNCTION_COLLECTION_PLUGIN, we came up to the following:
- The hash to lookup functions by name appeared to be redundant. We already have a hash to lookup plugins by name (and type). So this new hash looked really duplicate.
- It's not possible to maintain ref_count of individual functions. So some more code duplication is needed for dynamic plugins, to maintain reference counters.
After discussing, Serg and Bar decided that:
- For now we should go through a new plugin type, MariaDB_FUNCTION_PLUGIN, where each plugin exports a single function. We'll do flood the output of INFORMATION_SCHEMA.PLUGINS queries for now, but this is tolerable. It's more important to avoid code duplication.
- Eventually we'll add generic collection plugins with these characteristics:
- A generic collection plugin will be able to join multiple plugins, even of different types (e.g. a number of MariaDB_DATE_TYPE_PLUGINs and MariaDB_FUNCTION_PLUGINs) into a single instance, which will be available in some INFORMATION_SCHEMA table (either PLUGINS, or a new one) as a single record.
- A generic collection plugin will be able to do atomic initialization: either load all sub-plugins, or load non of them.
Under terms of this task we do the following:
- Implement MariaDB_FUNCTION_PLUGIN, to export individual functions.
- Change the code in /plugins/type_inet/ and /plugins/type_test/ to use MariaDB_FUNCTION_PLUGIN instead of MariaDB_FUNCTION_COLLECTION_PLUGIN.
- Remove MariaDB_FUNCTION_COLLECTION.
Attachments
Issue Links
- blocks
-
MDEV-274 The data type for IPv6/IPv4 addresses in MariaDB
-
- Closed
-
-
MDEV-4912 Data type plugin API version 1
-
- Closed
-
-
MDEV-20841 Turn GIS implementation into a plugin
-
- Open
-
-
MDEV-20842 Crash using versioning plugin functions after plugin was removed from server
-
- Closed
-
- causes
-
MDEV-34451 Document FUNCTION plugin type
-
- Open
-
- relates to
-
MDEV-20846 Add proper unlocking for MariaDB_FUNCTION_PLUGIN
-
- Open
-
-
MDEV-20764 Add MariaDB_FUNCTION_COLLECTION_PLUGIN
-
- Closed
-
-
MDEV-23290 Add overloading support in MariaDB_FUNCTION_PLUGIN
-
- Open
-
Activity
Field | Original Value | New Value |
---|---|---|
Link |
This issue relates to |
Rank | Ranked higher |
Description |
Originally, Serg and Bar decided to implement function plugins through MariaDB_FUNCTION_COLLECTION_PLUGIN, so a plugin can export multiple functions at the same type.
The retionale of this solution was to avoid flooding the output of this query: {code:sq} SELECT * FROM INFORMATION_SCHEMA.PLUGINS; {code} For example, we have 155 GEOMETRY related functions. Exporting all 155 function as individual plugins would add 155 entries to the query output. After adding MariaDB_FUNCTION_COLLECTION_PLUGIN: - The hash to lookup functions by name appeared to be redundant. We already have a hash to lookup plugins by name (and type). So this new hash looked really redundant. - It's not possible to maintain ref_count of individual functions. So some more code duplication is needed for dynamic plugins. After discussing, Serg and Bar decided that: - For now we should go through a new plugin type, MariaDB_FUNCTION_PLUGIN, where each plugin exports a single function. We'll do flood the output of INFORMATION_SCHEMA.PLUGINS queries for now, but this is tolerable. It's more important to avoid code duplication. - Eventually we'll add generic collection plugins with this characteristics: -- A generic collection plugin will be able to join multiple plugins, even of different types (e.g. a number of MariaDB_DATE_TYPE_PLUGINs and MariaDB_FUNCTION_PLUGINs) into a single instance, which will be available in INFORMATION_SCHEMA as a single record. -- A generic collection plugin will be able to do atomic initialization: either load all sub-plugins, or load non of them. Under terms of this task we do the following: - Implement MariaDB_FUNCTION_PLUGIN, to export individual functions. - Change the code in /plugins/type_inet/ and /plugins/type_test/ to use MariaDB_FUNCTION_PLUGIN instead of MariaDB_FUNCTION_COLLECTION_PLUGIN - Remove MariaDB_FUNCTION_COLLECTION. |
Originally, Serg and Bar decided to implement function plugins through MariaDB_FUNCTION_COLLECTION_PLUGIN, so a plugin can export multiple functions at the same type.
The retionale of this solution was to avoid flooding the output of this query: {code:sq} SELECT * FROM INFORMATION_SCHEMA.PLUGINS; {code} For example, we have 155 GEOMETRY related functions. Exporting all 155 function as individual plugins would add 155 entries to the query output. After adding MariaDB_FUNCTION_COLLECTION_PLUGIN: - The hash to lookup functions by name appeared to be redundant. We already have a hash to lookup plugins by name (and type). So this new hash looked really redundant. - It's not possible to maintain ref_count of individual functions. So some more code duplication is needed for dynamic plugins. After discussing, Serg and Bar decided that: - For now we should go through a new plugin type, MariaDB_FUNCTION_PLUGIN, where each plugin exports a single function. We'll do flood the output of INFORMATION_SCHEMA.PLUGINS queries for now, but this is tolerable. It's more important to avoid code duplication. - Eventually we'll add generic collection plugins with this characteristics: -- A generic collection plugin will be able to join multiple plugins, even of different types (e.g. a number of MariaDB_DATE_TYPE_PLUGINs and MariaDB_FUNCTION_PLUGINs) into a single instance, which will be available in INFORMATION_SCHEMA as a single record. -- A generic collection plugin will be able to do atomic initialization: either load all sub-plugins, or load non of them. Under terms of this task we do the following: - Implement MariaDB_FUNCTION_PLUGIN, to export individual functions. - Change the code in /plugins/type_inet/ and /plugins/type_test/ to use MariaDB_FUNCTION_PLUGIN instead of MariaDB_FUNCTION_COLLECTION_PLUGIN. - Remove MariaDB_FUNCTION_COLLECTION. |
Description |
Originally, Serg and Bar decided to implement function plugins through MariaDB_FUNCTION_COLLECTION_PLUGIN, so a plugin can export multiple functions at the same type.
The retionale of this solution was to avoid flooding the output of this query: {code:sq} SELECT * FROM INFORMATION_SCHEMA.PLUGINS; {code} For example, we have 155 GEOMETRY related functions. Exporting all 155 function as individual plugins would add 155 entries to the query output. After adding MariaDB_FUNCTION_COLLECTION_PLUGIN: - The hash to lookup functions by name appeared to be redundant. We already have a hash to lookup plugins by name (and type). So this new hash looked really redundant. - It's not possible to maintain ref_count of individual functions. So some more code duplication is needed for dynamic plugins. After discussing, Serg and Bar decided that: - For now we should go through a new plugin type, MariaDB_FUNCTION_PLUGIN, where each plugin exports a single function. We'll do flood the output of INFORMATION_SCHEMA.PLUGINS queries for now, but this is tolerable. It's more important to avoid code duplication. - Eventually we'll add generic collection plugins with this characteristics: -- A generic collection plugin will be able to join multiple plugins, even of different types (e.g. a number of MariaDB_DATE_TYPE_PLUGINs and MariaDB_FUNCTION_PLUGINs) into a single instance, which will be available in INFORMATION_SCHEMA as a single record. -- A generic collection plugin will be able to do atomic initialization: either load all sub-plugins, or load non of them. Under terms of this task we do the following: - Implement MariaDB_FUNCTION_PLUGIN, to export individual functions. - Change the code in /plugins/type_inet/ and /plugins/type_test/ to use MariaDB_FUNCTION_PLUGIN instead of MariaDB_FUNCTION_COLLECTION_PLUGIN. - Remove MariaDB_FUNCTION_COLLECTION. |
Originally, Serg and Bar decided to implement function plugins through MariaDB_FUNCTION_COLLECTION_PLUGIN, so a plugin can export multiple functions at the same type.
The retionale of this solution was to avoid flooding the output of this query: {code:sq} SELECT * FROM INFORMATION_SCHEMA.PLUGINS; {code} For example, we have 155 GEOMETRY related functions. Exporting all 155 function as individual plugins would add 155 entries to the query output. After adding MariaDB_FUNCTION_COLLECTION_PLUGIN, we came up to the following: - The hash to lookup functions by name appeared to be redundant. We already have a hash to lookup plugins by name (and type). So this new hash looked really redundant. - It's not possible to maintain ref_count of individual functions. So some more code duplication is needed for dynamic plugins. After discussing, Serg and Bar decided that: - For now we should go through a new plugin type, MariaDB_FUNCTION_PLUGIN, where each plugin exports a single function. We'll do flood the output of INFORMATION_SCHEMA.PLUGINS queries for now, but this is tolerable. It's more important to avoid code duplication. - Eventually we'll add generic collection plugins with this characteristics: -- A generic collection plugin will be able to join multiple plugins, even of different types (e.g. a number of MariaDB_DATE_TYPE_PLUGINs and MariaDB_FUNCTION_PLUGINs) into a single instance, which will be available in INFORMATION_SCHEMA as a single record. -- A generic collection plugin will be able to do atomic initialization: either load all sub-plugins, or load non of them. Under terms of this task we do the following: - Implement MariaDB_FUNCTION_PLUGIN, to export individual functions. - Change the code in /plugins/type_inet/ and /plugins/type_test/ to use MariaDB_FUNCTION_PLUGIN instead of MariaDB_FUNCTION_COLLECTION_PLUGIN. - Remove MariaDB_FUNCTION_COLLECTION. |
Description |
Originally, Serg and Bar decided to implement function plugins through MariaDB_FUNCTION_COLLECTION_PLUGIN, so a plugin can export multiple functions at the same type.
The retionale of this solution was to avoid flooding the output of this query: {code:sq} SELECT * FROM INFORMATION_SCHEMA.PLUGINS; {code} For example, we have 155 GEOMETRY related functions. Exporting all 155 function as individual plugins would add 155 entries to the query output. After adding MariaDB_FUNCTION_COLLECTION_PLUGIN, we came up to the following: - The hash to lookup functions by name appeared to be redundant. We already have a hash to lookup plugins by name (and type). So this new hash looked really redundant. - It's not possible to maintain ref_count of individual functions. So some more code duplication is needed for dynamic plugins. After discussing, Serg and Bar decided that: - For now we should go through a new plugin type, MariaDB_FUNCTION_PLUGIN, where each plugin exports a single function. We'll do flood the output of INFORMATION_SCHEMA.PLUGINS queries for now, but this is tolerable. It's more important to avoid code duplication. - Eventually we'll add generic collection plugins with this characteristics: -- A generic collection plugin will be able to join multiple plugins, even of different types (e.g. a number of MariaDB_DATE_TYPE_PLUGINs and MariaDB_FUNCTION_PLUGINs) into a single instance, which will be available in INFORMATION_SCHEMA as a single record. -- A generic collection plugin will be able to do atomic initialization: either load all sub-plugins, or load non of them. Under terms of this task we do the following: - Implement MariaDB_FUNCTION_PLUGIN, to export individual functions. - Change the code in /plugins/type_inet/ and /plugins/type_test/ to use MariaDB_FUNCTION_PLUGIN instead of MariaDB_FUNCTION_COLLECTION_PLUGIN. - Remove MariaDB_FUNCTION_COLLECTION. |
Originally, Serg and Bar decided to implement function plugins through MariaDB_FUNCTION_COLLECTION_PLUGIN, so a plugin can export multiple functions at the same type.
The retionale of this solution was to avoid flooding the output of this query: {code:sq} SELECT * FROM INFORMATION_SCHEMA.PLUGINS; {code} For example, we have 155 GEOMETRY related functions. Exporting all 155 function as individual plugins would add 155 entries to the query output. After adding MariaDB_FUNCTION_COLLECTION_PLUGIN, we came up to the following: - The hash to lookup functions by name appeared to be redundant. We already have a hash to lookup plugins by name (and type). So this new hash looked really duplicate. - It's not possible to maintain ref_count of individual functions. So some more code duplication is needed for dynamic plugins. After discussing, Serg and Bar decided that: - For now we should go through a new plugin type, MariaDB_FUNCTION_PLUGIN, where each plugin exports a single function. We'll do flood the output of INFORMATION_SCHEMA.PLUGINS queries for now, but this is tolerable. It's more important to avoid code duplication. - Eventually we'll add generic collection plugins with this characteristics: -- A generic collection plugin will be able to join multiple plugins, even of different types (e.g. a number of MariaDB_DATE_TYPE_PLUGINs and MariaDB_FUNCTION_PLUGINs) into a single instance, which will be available in INFORMATION_SCHEMA as a single record. -- A generic collection plugin will be able to do atomic initialization: either load all sub-plugins, or load non of them. Under terms of this task we do the following: - Implement MariaDB_FUNCTION_PLUGIN, to export individual functions. - Change the code in /plugins/type_inet/ and /plugins/type_test/ to use MariaDB_FUNCTION_PLUGIN instead of MariaDB_FUNCTION_COLLECTION_PLUGIN. - Remove MariaDB_FUNCTION_COLLECTION. |
Description |
Originally, Serg and Bar decided to implement function plugins through MariaDB_FUNCTION_COLLECTION_PLUGIN, so a plugin can export multiple functions at the same type.
The retionale of this solution was to avoid flooding the output of this query: {code:sq} SELECT * FROM INFORMATION_SCHEMA.PLUGINS; {code} For example, we have 155 GEOMETRY related functions. Exporting all 155 function as individual plugins would add 155 entries to the query output. After adding MariaDB_FUNCTION_COLLECTION_PLUGIN, we came up to the following: - The hash to lookup functions by name appeared to be redundant. We already have a hash to lookup plugins by name (and type). So this new hash looked really duplicate. - It's not possible to maintain ref_count of individual functions. So some more code duplication is needed for dynamic plugins. After discussing, Serg and Bar decided that: - For now we should go through a new plugin type, MariaDB_FUNCTION_PLUGIN, where each plugin exports a single function. We'll do flood the output of INFORMATION_SCHEMA.PLUGINS queries for now, but this is tolerable. It's more important to avoid code duplication. - Eventually we'll add generic collection plugins with this characteristics: -- A generic collection plugin will be able to join multiple plugins, even of different types (e.g. a number of MariaDB_DATE_TYPE_PLUGINs and MariaDB_FUNCTION_PLUGINs) into a single instance, which will be available in INFORMATION_SCHEMA as a single record. -- A generic collection plugin will be able to do atomic initialization: either load all sub-plugins, or load non of them. Under terms of this task we do the following: - Implement MariaDB_FUNCTION_PLUGIN, to export individual functions. - Change the code in /plugins/type_inet/ and /plugins/type_test/ to use MariaDB_FUNCTION_PLUGIN instead of MariaDB_FUNCTION_COLLECTION_PLUGIN. - Remove MariaDB_FUNCTION_COLLECTION. |
Originally, Serg and Bar decided to implement function plugins through MariaDB_FUNCTION_COLLECTION_PLUGIN, so a plugin can export multiple functions at the same type.
The retionale of this solution was to avoid flooding the output of this query: {code:sq} SELECT * FROM INFORMATION_SCHEMA.PLUGINS; {code} For example, we have 155 GEOMETRY related functions. Exporting all 155 function as individual plugins would add 155 entries to the query output. After adding MariaDB_FUNCTION_COLLECTION_PLUGIN, we came up to the following: - The hash to lookup functions by name appeared to be redundant. We already have a hash to lookup plugins by name (and type). So this new hash looked really duplicate. - It's not possible to maintain ref_count of individual functions. So some more code duplication is needed for dynamic plugins, to maintain reference counters. After discussing, Serg and Bar decided that: - For now we should go through a new plugin type, MariaDB_FUNCTION_PLUGIN, where each plugin exports a single function. We'll do flood the output of INFORMATION_SCHEMA.PLUGINS queries for now, but this is tolerable. It's more important to avoid code duplication. - Eventually we'll add generic collection plugins with this characteristics: -- A generic collection plugin will be able to join multiple plugins, even of different types (e.g. a number of MariaDB_DATE_TYPE_PLUGINs and MariaDB_FUNCTION_PLUGINs) into a single instance, which will be available in INFORMATION_SCHEMA as a single record. -- A generic collection plugin will be able to do atomic initialization: either load all sub-plugins, or load non of them. Under terms of this task we do the following: - Implement MariaDB_FUNCTION_PLUGIN, to export individual functions. - Change the code in /plugins/type_inet/ and /plugins/type_test/ to use MariaDB_FUNCTION_PLUGIN instead of MariaDB_FUNCTION_COLLECTION_PLUGIN. - Remove MariaDB_FUNCTION_COLLECTION. |
Description |
Originally, Serg and Bar decided to implement function plugins through MariaDB_FUNCTION_COLLECTION_PLUGIN, so a plugin can export multiple functions at the same type.
The retionale of this solution was to avoid flooding the output of this query: {code:sq} SELECT * FROM INFORMATION_SCHEMA.PLUGINS; {code} For example, we have 155 GEOMETRY related functions. Exporting all 155 function as individual plugins would add 155 entries to the query output. After adding MariaDB_FUNCTION_COLLECTION_PLUGIN, we came up to the following: - The hash to lookup functions by name appeared to be redundant. We already have a hash to lookup plugins by name (and type). So this new hash looked really duplicate. - It's not possible to maintain ref_count of individual functions. So some more code duplication is needed for dynamic plugins, to maintain reference counters. After discussing, Serg and Bar decided that: - For now we should go through a new plugin type, MariaDB_FUNCTION_PLUGIN, where each plugin exports a single function. We'll do flood the output of INFORMATION_SCHEMA.PLUGINS queries for now, but this is tolerable. It's more important to avoid code duplication. - Eventually we'll add generic collection plugins with this characteristics: -- A generic collection plugin will be able to join multiple plugins, even of different types (e.g. a number of MariaDB_DATE_TYPE_PLUGINs and MariaDB_FUNCTION_PLUGINs) into a single instance, which will be available in INFORMATION_SCHEMA as a single record. -- A generic collection plugin will be able to do atomic initialization: either load all sub-plugins, or load non of them. Under terms of this task we do the following: - Implement MariaDB_FUNCTION_PLUGIN, to export individual functions. - Change the code in /plugins/type_inet/ and /plugins/type_test/ to use MariaDB_FUNCTION_PLUGIN instead of MariaDB_FUNCTION_COLLECTION_PLUGIN. - Remove MariaDB_FUNCTION_COLLECTION. |
Originally, Serg and Bar decided to implement function plugins through MariaDB_FUNCTION_COLLECTION_PLUGIN, so a plugin can export multiple functions at the same type.
The retionale of this solution was to avoid flooding the output of this query: {code:sq} SELECT * FROM INFORMATION_SCHEMA.PLUGINS; {code} For example, we have 155 GEOMETRY related functions. Exporting all 155 function as individual plugins would add 155 entries to the query output. After adding MariaDB_FUNCTION_COLLECTION_PLUGIN, we came up to the following: - The hash to lookup functions by name appeared to be redundant. We already have a hash to lookup plugins by name (and type). So this new hash looked really duplicate. - It's not possible to maintain ref_count of individual functions. So some more code duplication is needed for dynamic plugins, to maintain reference counters. After discussing, Serg and Bar decided that: - For now we should go through a new plugin type, MariaDB_FUNCTION_PLUGIN, where each plugin exports a single function. We'll do flood the output of INFORMATION_SCHEMA.PLUGINS queries for now, but this is tolerable. It's more important to avoid code duplication. - Eventually we'll add generic collection plugins with these characteristics: -- A generic collection plugin will be able to join multiple plugins, even of different types (e.g. a number of MariaDB_DATE_TYPE_PLUGINs and MariaDB_FUNCTION_PLUGINs) into a single instance, which will be available in INFORMATION_SCHEMA as a single record. -- A generic collection plugin will be able to do atomic initialization: either load all sub-plugins, or load non of them. Under terms of this task we do the following: - Implement MariaDB_FUNCTION_PLUGIN, to export individual functions. - Change the code in /plugins/type_inet/ and /plugins/type_test/ to use MariaDB_FUNCTION_PLUGIN instead of MariaDB_FUNCTION_COLLECTION_PLUGIN. - Remove MariaDB_FUNCTION_COLLECTION. |
Description |
Originally, Serg and Bar decided to implement function plugins through MariaDB_FUNCTION_COLLECTION_PLUGIN, so a plugin can export multiple functions at the same type.
The retionale of this solution was to avoid flooding the output of this query: {code:sq} SELECT * FROM INFORMATION_SCHEMA.PLUGINS; {code} For example, we have 155 GEOMETRY related functions. Exporting all 155 function as individual plugins would add 155 entries to the query output. After adding MariaDB_FUNCTION_COLLECTION_PLUGIN, we came up to the following: - The hash to lookup functions by name appeared to be redundant. We already have a hash to lookup plugins by name (and type). So this new hash looked really duplicate. - It's not possible to maintain ref_count of individual functions. So some more code duplication is needed for dynamic plugins, to maintain reference counters. After discussing, Serg and Bar decided that: - For now we should go through a new plugin type, MariaDB_FUNCTION_PLUGIN, where each plugin exports a single function. We'll do flood the output of INFORMATION_SCHEMA.PLUGINS queries for now, but this is tolerable. It's more important to avoid code duplication. - Eventually we'll add generic collection plugins with these characteristics: -- A generic collection plugin will be able to join multiple plugins, even of different types (e.g. a number of MariaDB_DATE_TYPE_PLUGINs and MariaDB_FUNCTION_PLUGINs) into a single instance, which will be available in INFORMATION_SCHEMA as a single record. -- A generic collection plugin will be able to do atomic initialization: either load all sub-plugins, or load non of them. Under terms of this task we do the following: - Implement MariaDB_FUNCTION_PLUGIN, to export individual functions. - Change the code in /plugins/type_inet/ and /plugins/type_test/ to use MariaDB_FUNCTION_PLUGIN instead of MariaDB_FUNCTION_COLLECTION_PLUGIN. - Remove MariaDB_FUNCTION_COLLECTION. |
Originally, Serg and Bar decided to implement function plugins through MariaDB_FUNCTION_COLLECTION_PLUGIN, so a plugin can export multiple functions at the same type.
The retionale of this solution was to avoid flooding the output of this query: {code:sq} SELECT * FROM INFORMATION_SCHEMA.PLUGINS; {code} For example, we have 155 GEOMETRY related functions. Exporting all 155 function as individual plugins would add 155 entries to the query output. After adding MariaDB_FUNCTION_COLLECTION_PLUGIN, we came up to the following: - The hash to lookup functions by name appeared to be redundant. We already have a hash to lookup plugins by name (and type). So this new hash looked really duplicate. - It's not possible to maintain ref_count of individual functions. So some more code duplication is needed for dynamic plugins, to maintain reference counters. After discussing, Serg and Bar decided that: - For now we should go through a new plugin type, MariaDB_FUNCTION_PLUGIN, where each plugin exports a single function. We'll do flood the output of INFORMATION_SCHEMA.PLUGINS queries for now, but this is tolerable. It's more important to avoid code duplication. - Eventually we'll add generic collection plugins with these characteristics: -- A generic collection plugin will be able to join multiple plugins, even of different types (e.g. a number of MariaDB_DATE_TYPE_PLUGINs and MariaDB_FUNCTION_PLUGINs) into a single instance, which will be available in some INFORMATION_SCHEMA table as a single record. -- A generic collection plugin will be able to do atomic initialization: either load all sub-plugins, or load non of them. Under terms of this task we do the following: - Implement MariaDB_FUNCTION_PLUGIN, to export individual functions. - Change the code in /plugins/type_inet/ and /plugins/type_test/ to use MariaDB_FUNCTION_PLUGIN instead of MariaDB_FUNCTION_COLLECTION_PLUGIN. - Remove MariaDB_FUNCTION_COLLECTION. |
Description |
Originally, Serg and Bar decided to implement function plugins through MariaDB_FUNCTION_COLLECTION_PLUGIN, so a plugin can export multiple functions at the same type.
The retionale of this solution was to avoid flooding the output of this query: {code:sq} SELECT * FROM INFORMATION_SCHEMA.PLUGINS; {code} For example, we have 155 GEOMETRY related functions. Exporting all 155 function as individual plugins would add 155 entries to the query output. After adding MariaDB_FUNCTION_COLLECTION_PLUGIN, we came up to the following: - The hash to lookup functions by name appeared to be redundant. We already have a hash to lookup plugins by name (and type). So this new hash looked really duplicate. - It's not possible to maintain ref_count of individual functions. So some more code duplication is needed for dynamic plugins, to maintain reference counters. After discussing, Serg and Bar decided that: - For now we should go through a new plugin type, MariaDB_FUNCTION_PLUGIN, where each plugin exports a single function. We'll do flood the output of INFORMATION_SCHEMA.PLUGINS queries for now, but this is tolerable. It's more important to avoid code duplication. - Eventually we'll add generic collection plugins with these characteristics: -- A generic collection plugin will be able to join multiple plugins, even of different types (e.g. a number of MariaDB_DATE_TYPE_PLUGINs and MariaDB_FUNCTION_PLUGINs) into a single instance, which will be available in some INFORMATION_SCHEMA table as a single record. -- A generic collection plugin will be able to do atomic initialization: either load all sub-plugins, or load non of them. Under terms of this task we do the following: - Implement MariaDB_FUNCTION_PLUGIN, to export individual functions. - Change the code in /plugins/type_inet/ and /plugins/type_test/ to use MariaDB_FUNCTION_PLUGIN instead of MariaDB_FUNCTION_COLLECTION_PLUGIN. - Remove MariaDB_FUNCTION_COLLECTION. |
Originally, Serg and Bar decided to implement function plugins through MariaDB_FUNCTION_COLLECTION_PLUGIN, so a plugin can export multiple functions at the same type.
The retionale of this solution was to avoid flooding the output of this query: {code:sq} SELECT * FROM INFORMATION_SCHEMA.PLUGINS; {code} For example, we have 155 GEOMETRY related functions. Exporting all 155 function as individual plugins would add 155 entries to the query output. After adding MariaDB_FUNCTION_COLLECTION_PLUGIN, we came up to the following: - The hash to lookup functions by name appeared to be redundant. We already have a hash to lookup plugins by name (and type). So this new hash looked really duplicate. - It's not possible to maintain ref_count of individual functions. So some more code duplication is needed for dynamic plugins, to maintain reference counters. After discussing, Serg and Bar decided that: - For now we should go through a new plugin type, MariaDB_FUNCTION_PLUGIN, where each plugin exports a single function. We'll do flood the output of INFORMATION_SCHEMA.PLUGINS queries for now, but this is tolerable. It's more important to avoid code duplication. - Eventually we'll add generic collection plugins with these characteristics: -- A generic collection plugin will be able to join multiple plugins, even of different types (e.g. a number of MariaDB_DATE_TYPE_PLUGINs and MariaDB_FUNCTION_PLUGINs) into a single instance, which will be available in some INFORMATION_SCHEMA table (either PLUGINS, or a new one) as a single record. -- A generic collection plugin will be able to do atomic initialization: either load all sub-plugins, or load non of them. Under terms of this task we do the following: - Implement MariaDB_FUNCTION_PLUGIN, to export individual functions. - Change the code in /plugins/type_inet/ and /plugins/type_test/ to use MariaDB_FUNCTION_PLUGIN instead of MariaDB_FUNCTION_COLLECTION_PLUGIN. - Remove MariaDB_FUNCTION_COLLECTION. |
Description |
Originally, Serg and Bar decided to implement function plugins through MariaDB_FUNCTION_COLLECTION_PLUGIN, so a plugin can export multiple functions at the same type.
The retionale of this solution was to avoid flooding the output of this query: {code:sq} SELECT * FROM INFORMATION_SCHEMA.PLUGINS; {code} For example, we have 155 GEOMETRY related functions. Exporting all 155 function as individual plugins would add 155 entries to the query output. After adding MariaDB_FUNCTION_COLLECTION_PLUGIN, we came up to the following: - The hash to lookup functions by name appeared to be redundant. We already have a hash to lookup plugins by name (and type). So this new hash looked really duplicate. - It's not possible to maintain ref_count of individual functions. So some more code duplication is needed for dynamic plugins, to maintain reference counters. After discussing, Serg and Bar decided that: - For now we should go through a new plugin type, MariaDB_FUNCTION_PLUGIN, where each plugin exports a single function. We'll do flood the output of INFORMATION_SCHEMA.PLUGINS queries for now, but this is tolerable. It's more important to avoid code duplication. - Eventually we'll add generic collection plugins with these characteristics: -- A generic collection plugin will be able to join multiple plugins, even of different types (e.g. a number of MariaDB_DATE_TYPE_PLUGINs and MariaDB_FUNCTION_PLUGINs) into a single instance, which will be available in some INFORMATION_SCHEMA table (either PLUGINS, or a new one) as a single record. -- A generic collection plugin will be able to do atomic initialization: either load all sub-plugins, or load non of them. Under terms of this task we do the following: - Implement MariaDB_FUNCTION_PLUGIN, to export individual functions. - Change the code in /plugins/type_inet/ and /plugins/type_test/ to use MariaDB_FUNCTION_PLUGIN instead of MariaDB_FUNCTION_COLLECTION_PLUGIN. - Remove MariaDB_FUNCTION_COLLECTION. |
Originally, Serg and Bar decided to implement function plugins through MariaDB_FUNCTION_COLLECTION_PLUGIN, so a plugin can export multiple SQL functions at the same type.
The retionale of this solution was to avoid flooding the output of this query: {code:sq} SELECT * FROM INFORMATION_SCHEMA.PLUGINS; {code} For example, we have 155 GEOMETRY related functions. Exporting all 155 function as individual plugins would add 155 entries to the query output. After adding MariaDB_FUNCTION_COLLECTION_PLUGIN, we came up to the following: - The hash to lookup functions by name appeared to be redundant. We already have a hash to lookup plugins by name (and type). So this new hash looked really duplicate. - It's not possible to maintain ref_count of individual functions. So some more code duplication is needed for dynamic plugins, to maintain reference counters. After discussing, Serg and Bar decided that: - For now we should go through a new plugin type, MariaDB_FUNCTION_PLUGIN, where each plugin exports a single function. We'll do flood the output of INFORMATION_SCHEMA.PLUGINS queries for now, but this is tolerable. It's more important to avoid code duplication. - Eventually we'll add generic collection plugins with these characteristics: -- A generic collection plugin will be able to join multiple plugins, even of different types (e.g. a number of MariaDB_DATE_TYPE_PLUGINs and MariaDB_FUNCTION_PLUGINs) into a single instance, which will be available in some INFORMATION_SCHEMA table (either PLUGINS, or a new one) as a single record. -- A generic collection plugin will be able to do atomic initialization: either load all sub-plugins, or load non of them. Under terms of this task we do the following: - Implement MariaDB_FUNCTION_PLUGIN, to export individual functions. - Change the code in /plugins/type_inet/ and /plugins/type_test/ to use MariaDB_FUNCTION_PLUGIN instead of MariaDB_FUNCTION_COLLECTION_PLUGIN. - Remove MariaDB_FUNCTION_COLLECTION. |
Link | This issue blocks MDEV-20841 [ MDEV-20841 ] |
Link |
This issue blocks |
Status | Open [ 1 ] | In Progress [ 3 ] |
Assignee | Alexander Barkov [ bar ] | Sergei Golubchik [ serg ] |
Status | In Progress [ 3 ] | In Review [ 10002 ] |
Link | This issue relates to MDEV-20846 [ MDEV-20846 ] |
Fix Version/s | 10.5.0 [ 23709 ] | |
Fix Version/s | 10.5 [ 23123 ] | |
Resolution | Fixed [ 1 ] | |
Status | In Review [ 10002 ] | Closed [ 6 ] |
Fixing Priority | 250 |
Link | This issue relates to MDEV-23290 [ MDEV-23290 ] |
Workflow | MariaDB v3 [ 100445 ] | MariaDB v4 [ 134116 ] |
Assignee | Sergei Golubchik [ serg ] | Alexander Barkov [ bar ] |
Link | This issue causes MDEV-34451 [ MDEV-34451 ] |
serg, please review:
https://github.com/MariaDB/server/commits/bb-10.5-bar