Details

    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

          Activity

            bar Alexander Barkov created issue -
            bar Alexander Barkov made changes -
            Field Original Value New Value
            bar Alexander Barkov made changes -
            Rank Ranked higher
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            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.
            bar Alexander Barkov made changes -
            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.
            bar Alexander Barkov made changes -
            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.
            bar Alexander Barkov made changes -
            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.
            bar Alexander Barkov made changes -
            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.
            bar Alexander Barkov made changes -
            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.
            bar Alexander Barkov made changes -
            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.
            bar Alexander Barkov made changes -
            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.
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            bar Alexander Barkov added a comment - serg , please review: https://github.com/MariaDB/server/commits/bb-10.5-bar
            bar Alexander Barkov made changes -
            Assignee Alexander Barkov [ bar ] Sergei Golubchik [ serg ]
            Status In Progress [ 3 ] In Review [ 10002 ]
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            Fix Version/s 10.5.0 [ 23709 ]
            Fix Version/s 10.5 [ 23123 ]
            Resolution Fixed [ 1 ]
            Status In Review [ 10002 ] Closed [ 6 ]
            julien.fritsch Julien Fritsch made changes -
            Fixing Priority 250
            bar Alexander Barkov made changes -
            serg Sergei Golubchik made changes -
            Workflow MariaDB v3 [ 100445 ] MariaDB v4 [ 134116 ]
            serg Sergei Golubchik made changes -
            Assignee Sergei Golubchik [ serg ] Alexander Barkov [ bar ]
            serg Sergei Golubchik made changes -

            People

              bar Alexander Barkov
              bar Alexander Barkov
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.