Details

    • Add a plugin to field types (column types)
    • 10.2.0-1, 10.2.0-2, 10.2.0-4, 10.2.0-5, 10.2.0-6, 10.2.0-7, 10.2.0-8, 10.2.1-1, 10.2.1-3, 10.2.1-4, 10.2.1-5, 10.2.2-3, 10.3.1-1

    Description

      Issues to solve:

      • read/write: that's easy, the plugin provides some kind of a "store" method that serializes the data into something that can be memcmp-ed. And "val" methods as appropriate.
      • indexing: not at issue, the engine thinks the column type is BINARY and indexes is accordingly
      • don't forget that field definition may use parameters, like in VARCHAR(10)
      • protocol
        • text protocol - what to send as field metadata? variant: MYSQL_TYPE_PLUGIN and a string with the type name
        • binary protocol - how to send the value to the client: variant: as a string. how the client send the value to the server? either way, the server converts it from number/string/etc just as for INSERTs
      • replication, RBR
        • similar, use MYSQL_TYPE_PLUGIN, and as additional metadata - field type as a string, parameters, whatever

      So, a plugin would need to provide

      • store() method from at least some of the basic types
      • val() methods to at least some of the basic types
      • description of whatever parameters a field definition takes
      • informational methods, like store_length(), etc

      This task doesn't cover everything! It is assumed that we can expand this API later to add more features. In particular, the following is not solved:

      • data types that cannot be efficiently memcmp()'ed. For example, this proposal doesn't allow to implement a string type with charset support.
      • data types that require special indexes, such as XML, spatial data, etc.

      see also the original issue description in the history

      Attachments

        Issue Links

          Activity

            rspadim roberto spadim created issue -
            rspadim roberto spadim made changes -
            Field Original Value New Value
            rspadim roberto spadim made changes -
            rspadim roberto spadim made changes -
            Description This MDEV will allow a plugin for field types, there's many MDEV and ideas over mysql/mariadb/percona/others forks, that want IPv6, Encrypted column, and others features, this is nice, but add many non standard code (but native code), the idea is allow this to be a plugin.

            for Alter table sintax we will have:
            {code}
            ALTER TABLE TABLE ...
            ADD field_name
            PLUGIN(<plugin info-1>,<plugin info-2>,<plugin info-3>,<plugin info-4>)
            NOT NULL/NULL
            AUTOINCREMENT
            DEFAULT
            ... others field parameters
            {code}
            <plugin info> will be saved at .FRM file, and informations here are:
            1)plugin name
            2)plugin version
            3)plugin column type name
            4)plugin column options

            let'me explain with a example based:
            {code}
            PLUGIN('CRYPT','1','SHA1',"PASSWORD=ABCDEFG,SIZE=255")
            {code}
            this kind of plugin, with name CRYPT, version 1, will use a SHA1 algorithm to crypt/decrypt information from disk, based in a varchar(255) field type
            internally plugin will have function to;
            1) send what bytes should be write, and what kind of field type will be used, here it will use normal mysql field types (VARCHAR,CHAR,INT,FLOAT,BLOB,TEXT,DECIMAL,DATE,DATETIME,TIME,GEOMETRY ...)
            2) read values from database
            3) compare values
            4) maybe optimize the <field> <operator> <constant> operations

            there's some problems.... first one, user interfaces (heidisql for example) will not know what type of information it will have just read the CREATE TABLE
            we could add more information to "SHOW COLUMNS FROM <table>", example:
            || *Field* || *Type* || *Null* || *Key* || *Default* || *Extra* || *Internal Type* ||
            | ID | PLUGIN('CRYPT','1','SHA1','PASSWORD=ABCEDFG,SIZE=255') | NO | | 0 | | VARCHAR(255) |


            it's a raw idea, and must be better checked, the main high level idea is here, low level should be considered before start work
            This MDEV will allow a plugin for field types, there's many MDEV and ideas over mysql/mariadb/percona/others forks, that want IPv6, Encrypted column, and others features, this is nice, but add many non standard code (but native code), the idea is allow this to be a plugin.

            for Alter table sintax we will have:
            {code}
            ALTER TABLE TABLE ...
            ADD field_name
            PLUGIN(<plugin info-1>,<plugin info-2>,<plugin info-3>,<plugin info-4>)
            NOT NULL/NULL
            AUTOINCREMENT
            DEFAULT
            ... others field parameters
            {code}
            <plugin info> will be saved at .FRM file, and informations here are:
            1)plugin name (same value of "SELECT PLUGIN_NAME FROM information_schema.PLUGINS")
            2)plugin version (same value of "SELECT PLUGIN_VERSION FROM information_schema.PLUGINS")
            3)plugin column type name (internal to plugin code)
            4)plugin column options (internal to plugin code)

            *THE FRM FILE WILL STORE THE PLUGIN FIELD TYPE, AND THE "INTERNAL ENGINE" TYPE, WHEN WE CAN'T LOAD THE PLUGIN WE COULD AT LEAST READ THE ENGINE INFORMATION INSTEAD OF A "CRASHED TABLE" PROBLEM*


            let'me explain with a example based:
            {code}
            PLUGIN('CRYPT','1','SHA1',"PASSWORD=ABCDEFG,SIZE=255")
            {code}
            this kind of plugin, with name CRYPT, version 1, will use a SHA1 algorithm to crypt/decrypt information from disk, based in a varchar(255) field type
            internally plugin will have function to;
            1) send what bytes should be write, and what kind of field type will be used, here it will use normal mysql field types (VARCHAR,CHAR,INT,FLOAT,BLOB,TEXT,DECIMAL,DATE,DATETIME,TIME,GEOMETRY ...)
            2) read values from database
            3) compare values
            4) maybe optimize the <field> <operator> <constant> operations

            there's some problems.... first one, user interfaces (heidisql for example) will not know what type of information it will have just read the CREATE TABLE
            we could add more information to "SHOW COLUMNS FROM <table>", example:
            || *Field* || *Type* || *Null* || *Key* || *Default* || *Extra* || *Internal Type* ||
            | ID | PLUGIN('CRYPT','1','SHA1','PASSWORD=ABCEDFG,SIZE=255') | NO | | 0 | | VARCHAR(255) |


            it's a raw idea, and must be better checked, the main high level idea is here, low level should be considered before start work

            more considerations about differente versions of the same plugin:
            we could add a 'automatic' alter table, when one plugin is upgrade from version 1 to version 2 for example, the plugin could read the old value, and write the new value, just a idea... the version is the same version parameter of PLUGIN field type, is the same value of "SELECT PLUGIN_VERSION FROM information_schema.PLUGINS"
            rspadim roberto spadim made changes -
            Description This MDEV will allow a plugin for field types, there's many MDEV and ideas over mysql/mariadb/percona/others forks, that want IPv6, Encrypted column, and others features, this is nice, but add many non standard code (but native code), the idea is allow this to be a plugin.

            for Alter table sintax we will have:
            {code}
            ALTER TABLE TABLE ...
            ADD field_name
            PLUGIN(<plugin info-1>,<plugin info-2>,<plugin info-3>,<plugin info-4>)
            NOT NULL/NULL
            AUTOINCREMENT
            DEFAULT
            ... others field parameters
            {code}
            <plugin info> will be saved at .FRM file, and informations here are:
            1)plugin name (same value of "SELECT PLUGIN_NAME FROM information_schema.PLUGINS")
            2)plugin version (same value of "SELECT PLUGIN_VERSION FROM information_schema.PLUGINS")
            3)plugin column type name (internal to plugin code)
            4)plugin column options (internal to plugin code)

            *THE FRM FILE WILL STORE THE PLUGIN FIELD TYPE, AND THE "INTERNAL ENGINE" TYPE, WHEN WE CAN'T LOAD THE PLUGIN WE COULD AT LEAST READ THE ENGINE INFORMATION INSTEAD OF A "CRASHED TABLE" PROBLEM*


            let'me explain with a example based:
            {code}
            PLUGIN('CRYPT','1','SHA1',"PASSWORD=ABCDEFG,SIZE=255")
            {code}
            this kind of plugin, with name CRYPT, version 1, will use a SHA1 algorithm to crypt/decrypt information from disk, based in a varchar(255) field type
            internally plugin will have function to;
            1) send what bytes should be write, and what kind of field type will be used, here it will use normal mysql field types (VARCHAR,CHAR,INT,FLOAT,BLOB,TEXT,DECIMAL,DATE,DATETIME,TIME,GEOMETRY ...)
            2) read values from database
            3) compare values
            4) maybe optimize the <field> <operator> <constant> operations

            there's some problems.... first one, user interfaces (heidisql for example) will not know what type of information it will have just read the CREATE TABLE
            we could add more information to "SHOW COLUMNS FROM <table>", example:
            || *Field* || *Type* || *Null* || *Key* || *Default* || *Extra* || *Internal Type* ||
            | ID | PLUGIN('CRYPT','1','SHA1','PASSWORD=ABCEDFG,SIZE=255') | NO | | 0 | | VARCHAR(255) |


            it's a raw idea, and must be better checked, the main high level idea is here, low level should be considered before start work

            more considerations about differente versions of the same plugin:
            we could add a 'automatic' alter table, when one plugin is upgrade from version 1 to version 2 for example, the plugin could read the old value, and write the new value, just a idea... the version is the same version parameter of PLUGIN field type, is the same value of "SELECT PLUGIN_VERSION FROM information_schema.PLUGINS"
            This MDEV will allow a plugin for field types, there's many MDEV and ideas over mysql/mariadb/percona/others forks, that want IPv6, Encrypted column, and others features, this is nice, but add many non standard code (but native code), the idea is allow this to be a plugin.

            *THIS MDEV IS A RAW IDEA, and MUST BE CHECKED! the main high level idea is here, low level should be considered before start work*


            for Alter table sintax we will have:
            {code}
            ALTER TABLE TABLE ...
            ADD field_name
            PLUGIN(<plugin info-1>,<plugin info-2>,<plugin info-3>,<plugin info-4>)
            NOT NULL/NULL
            AUTOINCREMENT
            DEFAULT
            ... others field parameters
            {code}
            <plugin info> will be saved at .FRM file, and informations here are:
            1)plugin name (same value of "SELECT PLUGIN_NAME FROM information_schema.PLUGINS")
            2)plugin version (same value of "SELECT PLUGIN_VERSION FROM information_schema.PLUGINS")
            3)plugin column type name (internal to plugin code)
            4)plugin column options (internal to plugin code)

            *THE FRM FILE WILL STORE THE PLUGIN FIELD TYPE, AND THE "INTERNAL ENGINE" TYPE, WHEN WE CAN'T LOAD THE PLUGIN WE COULD AT LEAST READ THE ENGINE INFORMATION INSTEAD OF A "CRASHED TABLE" PROBLEM*


            let'me explain with a example based:
            {code}
            PLUGIN('CRYPT','1','SHA1',"PASSWORD=ABCDEFG,SIZE=255")
            {code}
            this kind of plugin, with name CRYPT, version 1, will use a SHA1 algorithm to crypt/decrypt information from disk, based in a varchar(255) field type
            internally plugin will have function to;
            1) send what bytes should be write, and what kind of field type will be used, here it will use normal mysql field types (VARCHAR,CHAR,INT,FLOAT,BLOB,TEXT,DECIMAL,DATE,DATETIME,TIME,GEOMETRY ...)
            2) read values from database
            3) compare values
            4) maybe optimize the <field> <operator> <constant> operations

            there's some problems.... first one, user interfaces (heidisql for example) will not know what type of information it will have just read the CREATE TABLE
            we could add more information to "SHOW COLUMNS FROM <table>", example:
            || *Field* || *Type* || *Null* || *Key* || *Default* || *Extra* || *Internal Type* ||
            | ID | PLUGIN('CRYPT','1','SHA1','PASSWORD=ABCEDFG,SIZE=255') | NO | | 0 | | VARCHAR(255) |



            more considerations about differente versions of the same plugin:
            we could add a 'automatic' alter table, when one plugin is upgrade from version 1 to version 2 for example, the plugin could read the old value, and write the new value, just a idea... the version is the same version parameter of PLUGIN field type, is the same value of "SELECT PLUGIN_VERSION FROM information_schema.PLUGINS"

            We have some nice field type in PostgreSQL
            THE MAIN PROBLEM ABOUT THIS PLUGIN IS A NOT STANDARD ABOUT FIELD TYPES...
            for example XML functions of MYSQL 5.7 want a VARCHAR/CHAR/TEXT/BLOB as parameter, and a XML type could make some incompatibility...

            well more definition is need before add more considerations...

            rspadim roberto spadim added a comment - We have some nice field type in PostgreSQL THE MAIN PROBLEM ABOUT THIS PLUGIN IS A NOT STANDARD ABOUT FIELD TYPES... for example XML functions of MYSQL 5.7 want a VARCHAR/CHAR/TEXT/BLOB as parameter, and a XML type could make some incompatibility... well more definition is need before add more considerations...
            rspadim roberto spadim made changes -
            rspadim roberto spadim made changes -
            Description This MDEV will allow a plugin for field types, there's many MDEV and ideas over mysql/mariadb/percona/others forks, that want IPv6, Encrypted column, and others features, this is nice, but add many non standard code (but native code), the idea is allow this to be a plugin.

            *THIS MDEV IS A RAW IDEA, and MUST BE CHECKED! the main high level idea is here, low level should be considered before start work*


            for Alter table sintax we will have:
            {code}
            ALTER TABLE TABLE ...
            ADD field_name
            PLUGIN(<plugin info-1>,<plugin info-2>,<plugin info-3>,<plugin info-4>)
            NOT NULL/NULL
            AUTOINCREMENT
            DEFAULT
            ... others field parameters
            {code}
            <plugin info> will be saved at .FRM file, and informations here are:
            1)plugin name (same value of "SELECT PLUGIN_NAME FROM information_schema.PLUGINS")
            2)plugin version (same value of "SELECT PLUGIN_VERSION FROM information_schema.PLUGINS")
            3)plugin column type name (internal to plugin code)
            4)plugin column options (internal to plugin code)

            *THE FRM FILE WILL STORE THE PLUGIN FIELD TYPE, AND THE "INTERNAL ENGINE" TYPE, WHEN WE CAN'T LOAD THE PLUGIN WE COULD AT LEAST READ THE ENGINE INFORMATION INSTEAD OF A "CRASHED TABLE" PROBLEM*


            let'me explain with a example based:
            {code}
            PLUGIN('CRYPT','1','SHA1',"PASSWORD=ABCDEFG,SIZE=255")
            {code}
            this kind of plugin, with name CRYPT, version 1, will use a SHA1 algorithm to crypt/decrypt information from disk, based in a varchar(255) field type
            internally plugin will have function to;
            1) send what bytes should be write, and what kind of field type will be used, here it will use normal mysql field types (VARCHAR,CHAR,INT,FLOAT,BLOB,TEXT,DECIMAL,DATE,DATETIME,TIME,GEOMETRY ...)
            2) read values from database
            3) compare values
            4) maybe optimize the <field> <operator> <constant> operations

            there's some problems.... first one, user interfaces (heidisql for example) will not know what type of information it will have just read the CREATE TABLE
            we could add more information to "SHOW COLUMNS FROM <table>", example:
            || *Field* || *Type* || *Null* || *Key* || *Default* || *Extra* || *Internal Type* ||
            | ID | PLUGIN('CRYPT','1','SHA1','PASSWORD=ABCEDFG,SIZE=255') | NO | | 0 | | VARCHAR(255) |



            more considerations about differente versions of the same plugin:
            we could add a 'automatic' alter table, when one plugin is upgrade from version 1 to version 2 for example, the plugin could read the old value, and write the new value, just a idea... the version is the same version parameter of PLUGIN field type, is the same value of "SELECT PLUGIN_VERSION FROM information_schema.PLUGINS"
            This MDEV will allow a plugin for field types, there's many MDEV and ideas over mysql/mariadb/percona/others forks, that want IPv6, Encrypted column, and others features, this is nice, but add many non standard code (but native code), the idea is allow this to be a plugin, and not a native code.

            *THIS MDEV IS A RAW IDEA, and MUST BE CHECKED! the main high level idea is here, low level should be considered before start work*

            based on PostgrSQL definition "built-in general-purpose data types" is something that all MYSQL ENGINES know about field type, theses types is the current mysql types, and should be used by this field plugin.
            I WILL CALL IT AS "INTERNAL TYPE", TO STORAGE ENGINE I WILL CALL IT AS "STORAGE TYPE"

            for Alter table sintax we will have:
            {code}
            ALTER TABLE TABLE ...
            ADD field_name
            PLUGIN(<plugin info-1>,<plugin info-2>,<plugin info-3>,<plugin info-4>)
            NOT NULL/NULL
            AUTOINCREMENT
            DEFAULT
            ... others field parameters
            {code}
            <plugin info> will be saved at .FRM file, and informations here are:
            1)plugin name (same value of "SELECT PLUGIN_NAME FROM information_schema.PLUGINS")
            2)plugin version (same value of "SELECT PLUGIN_VERSION FROM information_schema.PLUGINS")
            3)plugin column type name (internal to plugin code)
            4)plugin column options (internal to plugin code)

            The plugin will "calculate" the "INTERNAL TYPE", "STORAGE TYPE", "INDEX TYPE" to be used
            # We must check if we need a *STORAGE TYPE* and a "INDEX TYPE", based that some colations could be used, and some optimizations could be used, index could be encrypted or for example we could write a string to storage, and a integer to index, *must check if this is possible with today internal mysql code*

            This information will be added to SHOW COLUMN command

            the FRM file will store the "FIELD TYPE", "STORAGE TYPE", "INDEX TYPE", "INTERNAL TYPE"
            we must add a global variable, "open_table_without_field_plugin_definition" it have 3 values:
            0=> don't open, report an error
            1=> open, and report a warning
            2=> open and don't report anything
            check that (1 and 2) make the table READ ONLY !!!! *we can't WRITE without the plugin loaded!!!*

            Let'me explain with a example how the plugin parameters should be used:
            {code}
            PLUGIN(
             'CRYPT',
             '1',
             'SHA1',
             "PASSWORD=ABCDEFG,SIZE=255"
            )
            {code}
            this kind of plugin, with name "CRYPT", version "1", will use a "SHA1" column (maybe a algorithm to crypt/decrypt information from disk), with parameters about password and "INTERNAL TYPE"=varchar(255)

            internally plugin will have function to: *(must be better defined)*

            1) read bytes from storage engine (STORAGE/INDEX TYPE) and send "decoded" field to mysql core (INTERNAL TYPE)
            2) read bytes from mysql core (INTERNAL TYPE) and send "encoded" bytes to storage engine (STORAGE/INDEX TYPE)
            3) compare values could/should/must be pass via PLUGIN, for example if we want a ENUM field plugin to use a external table as KEY(int)=>VALUE(string), we can call via PLUGIN interface, a select query to solve this, like:

            SELECT VALUE FROM TABLE WHERE VALUE="ID"
            UNION
            SELECT VALUE FROM TABLE WHERE KEY="ID"
            LIMIT 1

            4) optimize the "<field> <operator> <constant>" where operations

            there's some problems.... first one, user interfaces (heidisql for example) will not know what type of information it will have just read the CREATE TABLE
            we could add more information to "SHOW COLUMNS FROM <table>", example:
            || *Field* || *Type* || *Null* || *Key* || *Default* || *Extra* || *Internal Type* || *Storage Type* || *Index Type* ||
            | ID | PLUGIN('CRYPT','1','SHA1','PASSWORD=ABCEDFG,SIZE=255') | NO | | 0 | | VARCHAR(255) | BLOB | BLOB |


            more considerations about different versions of the same plugin:
            we could add a 'automatic' alter table, when one plugin is upgrade from version 1 to version 2 for example
            the plugin could read the old value, and write the new value, just an idea...
            rspadim roberto spadim made changes -
            Description This MDEV will allow a plugin for field types, there's many MDEV and ideas over mysql/mariadb/percona/others forks, that want IPv6, Encrypted column, and others features, this is nice, but add many non standard code (but native code), the idea is allow this to be a plugin, and not a native code.

            *THIS MDEV IS A RAW IDEA, and MUST BE CHECKED! the main high level idea is here, low level should be considered before start work*

            based on PostgrSQL definition "built-in general-purpose data types" is something that all MYSQL ENGINES know about field type, theses types is the current mysql types, and should be used by this field plugin.
            I WILL CALL IT AS "INTERNAL TYPE", TO STORAGE ENGINE I WILL CALL IT AS "STORAGE TYPE"

            for Alter table sintax we will have:
            {code}
            ALTER TABLE TABLE ...
            ADD field_name
            PLUGIN(<plugin info-1>,<plugin info-2>,<plugin info-3>,<plugin info-4>)
            NOT NULL/NULL
            AUTOINCREMENT
            DEFAULT
            ... others field parameters
            {code}
            <plugin info> will be saved at .FRM file, and informations here are:
            1)plugin name (same value of "SELECT PLUGIN_NAME FROM information_schema.PLUGINS")
            2)plugin version (same value of "SELECT PLUGIN_VERSION FROM information_schema.PLUGINS")
            3)plugin column type name (internal to plugin code)
            4)plugin column options (internal to plugin code)

            The plugin will "calculate" the "INTERNAL TYPE", "STORAGE TYPE", "INDEX TYPE" to be used
            # We must check if we need a *STORAGE TYPE* and a "INDEX TYPE", based that some colations could be used, and some optimizations could be used, index could be encrypted or for example we could write a string to storage, and a integer to index, *must check if this is possible with today internal mysql code*

            This information will be added to SHOW COLUMN command

            the FRM file will store the "FIELD TYPE", "STORAGE TYPE", "INDEX TYPE", "INTERNAL TYPE"
            we must add a global variable, "open_table_without_field_plugin_definition" it have 3 values:
            0=> don't open, report an error
            1=> open, and report a warning
            2=> open and don't report anything
            check that (1 and 2) make the table READ ONLY !!!! *we can't WRITE without the plugin loaded!!!*

            Let'me explain with a example how the plugin parameters should be used:
            {code}
            PLUGIN(
             'CRYPT',
             '1',
             'SHA1',
             "PASSWORD=ABCDEFG,SIZE=255"
            )
            {code}
            this kind of plugin, with name "CRYPT", version "1", will use a "SHA1" column (maybe a algorithm to crypt/decrypt information from disk), with parameters about password and "INTERNAL TYPE"=varchar(255)

            internally plugin will have function to: *(must be better defined)*

            1) read bytes from storage engine (STORAGE/INDEX TYPE) and send "decoded" field to mysql core (INTERNAL TYPE)
            2) read bytes from mysql core (INTERNAL TYPE) and send "encoded" bytes to storage engine (STORAGE/INDEX TYPE)
            3) compare values could/should/must be pass via PLUGIN, for example if we want a ENUM field plugin to use a external table as KEY(int)=>VALUE(string), we can call via PLUGIN interface, a select query to solve this, like:

            SELECT VALUE FROM TABLE WHERE VALUE="ID"
            UNION
            SELECT VALUE FROM TABLE WHERE KEY="ID"
            LIMIT 1

            4) optimize the "<field> <operator> <constant>" where operations

            there's some problems.... first one, user interfaces (heidisql for example) will not know what type of information it will have just read the CREATE TABLE
            we could add more information to "SHOW COLUMNS FROM <table>", example:
            || *Field* || *Type* || *Null* || *Key* || *Default* || *Extra* || *Internal Type* || *Storage Type* || *Index Type* ||
            | ID | PLUGIN('CRYPT','1','SHA1','PASSWORD=ABCEDFG,SIZE=255') | NO | | 0 | | VARCHAR(255) | BLOB | BLOB |


            more considerations about different versions of the same plugin:
            we could add a 'automatic' alter table, when one plugin is upgrade from version 1 to version 2 for example
            the plugin could read the old value, and write the new value, just an idea...
            This MDEV will allow a plugin for field types, there's many MDEV and ideas over mysql/mariadb/percona/others forks, that want IPv6, Encrypted column, and others features, this is nice, but add many non standard code (but native code), the idea is allow this to be a plugin, and not a native code.

            *THIS MDEV IS A RAW IDEA, and MUST BE CHECKED! the main high level idea is here, low level should be considered before start work*

            based on PostgrSQL definition "built-in general-purpose data types" is something that all MYSQL ENGINES know about field type, theses types is the current mysql types, and should be used by this field plugin.
            I WILL CALL IT AS "INTERNAL TYPE", TO STORAGE ENGINE I WILL CALL IT AS "STORAGE TYPE" AND FOR INDEX I WILL CALL IT AS "INDEX TYPE"

            for Alter table sintax we will have:
            {code}
            ALTER TABLE TABLE ...
            ADD field_name
            PLUGIN(<plugin info-1>,<plugin info-2>,<plugin info-3>,<plugin info-4>)
            NOT NULL/NULL
            AUTOINCREMENT
            DEFAULT
            ... others field parameters
            {code}
            <plugin info> will be saved at .FRM file, and informations here are:
            1)plugin name (same value of "SELECT PLUGIN_NAME FROM information_schema.PLUGINS")
            2)plugin version (same value of "SELECT PLUGIN_VERSION FROM information_schema.PLUGINS")
            3)plugin column type name (internal to plugin code)
            4)plugin column options (internal to plugin code)

            The plugin will "calculate" the "INTERNAL TYPE", "STORAGE TYPE", "INDEX TYPE" to be used
            # We must check if we need a *STORAGE TYPE* and a "INDEX TYPE", based that some colations could be used, and some optimizations could be used, index could be encrypted or for example we could write a string to storage, and a integer to index, *must check if this is possible with today internal mysql code*

            This information will be added to SHOW COLUMN command

            the FRM file will store the "FIELD TYPE", "STORAGE TYPE", "INDEX TYPE", "INTERNAL TYPE"
            we must add a global variable, "open_table_without_field_plugin_definition" it have 3 values:
            0=> don't open, report an error
            1=> open, and report a warning
            2=> open and don't report anything
            check that (1 and 2) make the table READ ONLY !!!! *we can't WRITE without the plugin loaded!!!*

            Let'me explain with a example how the plugin parameters should be used:
            {code}
            PLUGIN(
             'CRYPT',
             '1',
             'SHA1',
             "PASSWORD=ABCDEFG,SIZE=255"
            )
            {code}
            this kind of plugin, with name "CRYPT", version "1", will use a "SHA1" column (maybe a algorithm to crypt/decrypt information from disk), with parameters about password and "INTERNAL TYPE"=varchar(255)

            internally plugin will have function to: *(must be better defined)*

            1) read bytes from storage engine (STORAGE/INDEX TYPE) and send "decoded" field to mysql core (INTERNAL TYPE)
            2) read bytes from mysql core (INTERNAL TYPE) and send "encoded" bytes to storage engine (STORAGE/INDEX TYPE)
            3) compare values could/should/must be pass via PLUGIN, for example if we want a ENUM field plugin to use a external table as KEY(int)=>VALUE(string), we can call via PLUGIN interface, a select query to solve this, like:

            SELECT VALUE FROM TABLE WHERE VALUE="ID"
            UNION
            SELECT VALUE FROM TABLE WHERE KEY="ID"
            LIMIT 1

            4) optimize the "<field> <operator> <constant>" where operations

            there's some problems.... first one, user interfaces (heidisql for example) will not know what type of information it will have just read the CREATE TABLE
            we could add more information to "SHOW COLUMNS FROM <table>", example:
            || *Field* || *Type* || *Null* || *Key* || *Default* || *Extra* || *Internal Type* || *Storage Type* || *Index Type* ||
            | ID | PLUGIN('CRYPT','1','SHA1','PASSWORD=ABCEDFG,SIZE=255') | NO | | 0 | | VARCHAR(255) | BLOB | BLOB |


            more considerations about different versions of the same plugin:
            we could add a 'automatic' alter table, when one plugin is upgrade from version 1 to version 2 for example
            the plugin could read the old value, and write the new value, just an idea...
            rspadim roberto spadim made changes -
            Description This MDEV will allow a plugin for field types, there's many MDEV and ideas over mysql/mariadb/percona/others forks, that want IPv6, Encrypted column, and others features, this is nice, but add many non standard code (but native code), the idea is allow this to be a plugin, and not a native code.

            *THIS MDEV IS A RAW IDEA, and MUST BE CHECKED! the main high level idea is here, low level should be considered before start work*

            based on PostgrSQL definition "built-in general-purpose data types" is something that all MYSQL ENGINES know about field type, theses types is the current mysql types, and should be used by this field plugin.
            I WILL CALL IT AS "INTERNAL TYPE", TO STORAGE ENGINE I WILL CALL IT AS "STORAGE TYPE" AND FOR INDEX I WILL CALL IT AS "INDEX TYPE"

            for Alter table sintax we will have:
            {code}
            ALTER TABLE TABLE ...
            ADD field_name
            PLUGIN(<plugin info-1>,<plugin info-2>,<plugin info-3>,<plugin info-4>)
            NOT NULL/NULL
            AUTOINCREMENT
            DEFAULT
            ... others field parameters
            {code}
            <plugin info> will be saved at .FRM file, and informations here are:
            1)plugin name (same value of "SELECT PLUGIN_NAME FROM information_schema.PLUGINS")
            2)plugin version (same value of "SELECT PLUGIN_VERSION FROM information_schema.PLUGINS")
            3)plugin column type name (internal to plugin code)
            4)plugin column options (internal to plugin code)

            The plugin will "calculate" the "INTERNAL TYPE", "STORAGE TYPE", "INDEX TYPE" to be used
            # We must check if we need a *STORAGE TYPE* and a "INDEX TYPE", based that some colations could be used, and some optimizations could be used, index could be encrypted or for example we could write a string to storage, and a integer to index, *must check if this is possible with today internal mysql code*

            This information will be added to SHOW COLUMN command

            the FRM file will store the "FIELD TYPE", "STORAGE TYPE", "INDEX TYPE", "INTERNAL TYPE"
            we must add a global variable, "open_table_without_field_plugin_definition" it have 3 values:
            0=> don't open, report an error
            1=> open, and report a warning
            2=> open and don't report anything
            check that (1 and 2) make the table READ ONLY !!!! *we can't WRITE without the plugin loaded!!!*

            Let'me explain with a example how the plugin parameters should be used:
            {code}
            PLUGIN(
             'CRYPT',
             '1',
             'SHA1',
             "PASSWORD=ABCDEFG,SIZE=255"
            )
            {code}
            this kind of plugin, with name "CRYPT", version "1", will use a "SHA1" column (maybe a algorithm to crypt/decrypt information from disk), with parameters about password and "INTERNAL TYPE"=varchar(255)

            internally plugin will have function to: *(must be better defined)*

            1) read bytes from storage engine (STORAGE/INDEX TYPE) and send "decoded" field to mysql core (INTERNAL TYPE)
            2) read bytes from mysql core (INTERNAL TYPE) and send "encoded" bytes to storage engine (STORAGE/INDEX TYPE)
            3) compare values could/should/must be pass via PLUGIN, for example if we want a ENUM field plugin to use a external table as KEY(int)=>VALUE(string), we can call via PLUGIN interface, a select query to solve this, like:

            SELECT VALUE FROM TABLE WHERE VALUE="ID"
            UNION
            SELECT VALUE FROM TABLE WHERE KEY="ID"
            LIMIT 1

            4) optimize the "<field> <operator> <constant>" where operations

            there's some problems.... first one, user interfaces (heidisql for example) will not know what type of information it will have just read the CREATE TABLE
            we could add more information to "SHOW COLUMNS FROM <table>", example:
            || *Field* || *Type* || *Null* || *Key* || *Default* || *Extra* || *Internal Type* || *Storage Type* || *Index Type* ||
            | ID | PLUGIN('CRYPT','1','SHA1','PASSWORD=ABCEDFG,SIZE=255') | NO | | 0 | | VARCHAR(255) | BLOB | BLOB |


            more considerations about different versions of the same plugin:
            we could add a 'automatic' alter table, when one plugin is upgrade from version 1 to version 2 for example
            the plugin could read the old value, and write the new value, just an idea...
            This MDEV will allow a plugin for field types, there's many MDEV and ideas over mysql/mariadb/percona/others forks, that want IPv6, Encrypted column, and others features, this is nice, but add many non standard code (but native code), the idea is allow this to be a plugin, and not a native code.

            *THIS MDEV IS A RAW IDEA, and MUST BE CHECKED! the main high level idea is here, low level should be considered before start work*

            based on PostgrSQL definition "built-in general-purpose data types" is something that all MYSQL ENGINES know about field type, theses types is the current mysql types, and should be used by this field plugin.
            I WILL CALL IT AS "INTERNAL TYPE", TO STORAGE ENGINE I WILL CALL IT AS "STORAGE TYPE" AND FOR INDEX I WILL CALL IT AS "INDEX TYPE"

            ---

            for Alter table sintax we will have:
            {code}
            ALTER TABLE TABLE ...
            ADD field_name
            PLUGIN(<plugin info-1>,<plugin info-2>,<plugin info-3>,<plugin info-4>)
            NOT NULL/NULL
            AUTOINCREMENT
            DEFAULT
            ... others field parameters, the point here is only the FIELD TYPE,others parameters will exists, and will be used when possible, but plugin will return a error if it don't support for example a default value, or a not null, null or autoincrement
            {code}

            <plugin info> will be saved at .FRM file, and informations here are:
            1)plugin name (same value of "SELECT PLUGIN_NAME FROM information_schema.PLUGINS")
            2)plugin version (same value of "SELECT PLUGIN_VERSION FROM information_schema.PLUGINS")
            3)plugin column type name (internal to plugin code)
            4)plugin column options (internal to plugin code)

            The plugin will "calculate" the "INTERNAL TYPE", "STORAGE TYPE", "INDEX TYPE" to be used
            # We must check if we need a *STORAGE TYPE* and a "INDEX TYPE", based that some colations could be used, and some optimizations could be used, index could be encrypted or for example we could write a string to storage, and a integer to index, *must check if this is possible with today internal mysql code*

            This information will be added to SHOW COLUMN command

            the FRM file will store the "FIELD TYPE", "STORAGE TYPE", "INDEX TYPE", "INTERNAL TYPE"
            we must add a global variable, "open_table_without_field_plugin_definition" it have 3 values:
            0=> don't open, report an error
            1=> open, and report a warning
            2=> open and don't report anything
            check that (1 and 2) make the table READ ONLY !!!! *we can't WRITE without the plugin loaded!!!*

            Let'me explain with a example how the plugin parameters should be used:
            {code}
            PLUGIN(
             'CRYPT',
             '1',
             'SHA1',
             "PASSWORD=ABCDEFG,SIZE=255"
            )
            {code}
            this kind of plugin, with name "CRYPT", version "1", will use a "SHA1" column (maybe a algorithm to crypt/decrypt information from disk), with parameters about password and "INTERNAL TYPE"=varchar(255)

            internally plugin will have function to: *(must be better defined)*

            1) read bytes from storage engine (STORAGE/INDEX TYPE) and send "decoded" field to mysql core (INTERNAL TYPE)
            2) read bytes from mysql core (INTERNAL TYPE) and send "encoded" bytes to storage engine (STORAGE/INDEX TYPE)
            3) compare values could/should/must be pass via PLUGIN, for example if we want a ENUM field plugin to use a external table as KEY(int)=>VALUE(string), we can call via PLUGIN interface, a select query to solve this, like:

            SELECT VALUE FROM TABLE WHERE VALUE="ID"
            UNION
            SELECT VALUE FROM TABLE WHERE KEY="ID"
            LIMIT 1

            4) optimize the "<field> <operator> <constant>" where operations

            there's some problems.... first one, user interfaces (heidisql for example) will not know what type of information it will have just read the CREATE TABLE
            we could add more information to "SHOW COLUMNS FROM <table>", example:
            || *Field* || *Type* || *Null* || *Key* || *Default* || *Extra* || *Internal Type* || *Storage Type* || *Index Type* ||
            | ID | PLUGIN('CRYPT','1','SHA1','PASSWORD=ABCEDFG,SIZE=255') | NO | | 0 | | VARCHAR(255) | BLOB | BLOB |


            more considerations about different versions of the same plugin:
            we could add a 'automatic' alter table, when one plugin is upgrade from version 1 to version 2 for example
            the plugin could read the old value, and write the new value, just an idea...
            rspadim roberto spadim made changes -
            Description This MDEV will allow a plugin for field types, there's many MDEV and ideas over mysql/mariadb/percona/others forks, that want IPv6, Encrypted column, and others features, this is nice, but add many non standard code (but native code), the idea is allow this to be a plugin, and not a native code.

            *THIS MDEV IS A RAW IDEA, and MUST BE CHECKED! the main high level idea is here, low level should be considered before start work*

            based on PostgrSQL definition "built-in general-purpose data types" is something that all MYSQL ENGINES know about field type, theses types is the current mysql types, and should be used by this field plugin.
            I WILL CALL IT AS "INTERNAL TYPE", TO STORAGE ENGINE I WILL CALL IT AS "STORAGE TYPE" AND FOR INDEX I WILL CALL IT AS "INDEX TYPE"

            ---

            for Alter table sintax we will have:
            {code}
            ALTER TABLE TABLE ...
            ADD field_name
            PLUGIN(<plugin info-1>,<plugin info-2>,<plugin info-3>,<plugin info-4>)
            NOT NULL/NULL
            AUTOINCREMENT
            DEFAULT
            ... others field parameters, the point here is only the FIELD TYPE,others parameters will exists, and will be used when possible, but plugin will return a error if it don't support for example a default value, or a not null, null or autoincrement
            {code}

            <plugin info> will be saved at .FRM file, and informations here are:
            1)plugin name (same value of "SELECT PLUGIN_NAME FROM information_schema.PLUGINS")
            2)plugin version (same value of "SELECT PLUGIN_VERSION FROM information_schema.PLUGINS")
            3)plugin column type name (internal to plugin code)
            4)plugin column options (internal to plugin code)

            The plugin will "calculate" the "INTERNAL TYPE", "STORAGE TYPE", "INDEX TYPE" to be used
            # We must check if we need a *STORAGE TYPE* and a "INDEX TYPE", based that some colations could be used, and some optimizations could be used, index could be encrypted or for example we could write a string to storage, and a integer to index, *must check if this is possible with today internal mysql code*

            This information will be added to SHOW COLUMN command

            the FRM file will store the "FIELD TYPE", "STORAGE TYPE", "INDEX TYPE", "INTERNAL TYPE"
            we must add a global variable, "open_table_without_field_plugin_definition" it have 3 values:
            0=> don't open, report an error
            1=> open, and report a warning
            2=> open and don't report anything
            check that (1 and 2) make the table READ ONLY !!!! *we can't WRITE without the plugin loaded!!!*

            Let'me explain with a example how the plugin parameters should be used:
            {code}
            PLUGIN(
             'CRYPT',
             '1',
             'SHA1',
             "PASSWORD=ABCDEFG,SIZE=255"
            )
            {code}
            this kind of plugin, with name "CRYPT", version "1", will use a "SHA1" column (maybe a algorithm to crypt/decrypt information from disk), with parameters about password and "INTERNAL TYPE"=varchar(255)

            internally plugin will have function to: *(must be better defined)*

            1) read bytes from storage engine (STORAGE/INDEX TYPE) and send "decoded" field to mysql core (INTERNAL TYPE)
            2) read bytes from mysql core (INTERNAL TYPE) and send "encoded" bytes to storage engine (STORAGE/INDEX TYPE)
            3) compare values could/should/must be pass via PLUGIN, for example if we want a ENUM field plugin to use a external table as KEY(int)=>VALUE(string), we can call via PLUGIN interface, a select query to solve this, like:

            SELECT VALUE FROM TABLE WHERE VALUE="ID"
            UNION
            SELECT VALUE FROM TABLE WHERE KEY="ID"
            LIMIT 1

            4) optimize the "<field> <operator> <constant>" where operations

            there's some problems.... first one, user interfaces (heidisql for example) will not know what type of information it will have just read the CREATE TABLE
            we could add more information to "SHOW COLUMNS FROM <table>", example:
            || *Field* || *Type* || *Null* || *Key* || *Default* || *Extra* || *Internal Type* || *Storage Type* || *Index Type* ||
            | ID | PLUGIN('CRYPT','1','SHA1','PASSWORD=ABCEDFG,SIZE=255') | NO | | 0 | | VARCHAR(255) | BLOB | BLOB |


            more considerations about different versions of the same plugin:
            we could add a 'automatic' alter table, when one plugin is upgrade from version 1 to version 2 for example
            the plugin could read the old value, and write the new value, just an idea...
            This MDEV will allow a plugin for field types, there's many MDEV and ideas over mysql/mariadb/percona/others forks, that want IPv6, Encrypted column, and others features, this is nice, but add many non standard code (but native code), the idea is allow this to be a plugin, and not a native code.

            *THIS MDEV IS A RAW IDEA, and MUST BE CHECKED! the main high level idea is here, low level should be considered before start work*

            based on PostgrSQL definition "built-in general-purpose data types" is something that all MYSQL ENGINES know about field type, theses types is the current mysql types, and should be used by this field plugin.
            I WILL CALL IT AS "INTERNAL TYPE", TO STORAGE ENGINE I WILL CALL IT AS "STORAGE TYPE" AND FOR INDEX I WILL CALL IT AS "INDEX TYPE"

            ---

            for Alter table sintax we will have:
            {code}
            ALTER TABLE TABLE ...
            ADD field_name
            PLUGIN(<plugin info-1>,<plugin info-2>,<plugin info-3>,<plugin info-4>)
            NOT NULL/NULL
            AUTOINCREMENT
            DEFAULT
            ... others field parameters, the point here is only the FIELD TYPE,others parameters will exists, and will be used when possible, but plugin will return a error if it don't support for example a default value, or a not null, null or autoincrement
            {code}

            <plugin info> will be saved at .FRM file, and informations here are:
            #plugin name (same value of "SELECT PLUGIN_NAME FROM information_schema.PLUGINS")
            #plugin version (same value of "SELECT PLUGIN_VERSION FROM information_schema.PLUGINS")
            #plugin column type name (internal to plugin code)
            #plugin column options (internal to plugin code)

            The plugin will "calculate" the "INTERNAL TYPE", "STORAGE TYPE", "INDEX TYPE" to be used
            # We must check if we need a *STORAGE TYPE* and a "INDEX TYPE", based that some colations could be used, and some optimizations could be used, index could be encrypted or for example we could write a string to storage, and a integer to index, *must check if this is possible with today internal mysql code*

            This information will be added to SHOW COLUMN command

            the FRM file will store the "FIELD TYPE", "STORAGE TYPE", "INDEX TYPE", "INTERNAL TYPE"
            we must add a global variable, "open_table_without_field_plugin_definition" it have 3 values:
            0=> don't open, report an error
            1=> open, and report a warning
            2=> open and don't report anything
            check that (1 and 2) make the table READ ONLY !!!! *we can't WRITE without the plugin loaded!!!*

            Let'me explain with a example how the plugin parameters should be used:
            {code}
            PLUGIN(
             'CRYPT',
             '1',
             'SHA1',
             "PASSWORD=ABCDEFG,SIZE=255"
            )
            {code}
            this kind of plugin, with name "CRYPT", version "1", will use a "SHA1" column (maybe a algorithm to crypt/decrypt information from disk), with parameters about password and "INTERNAL TYPE"=varchar(255)

            internally plugin will have function to: *(must be better defined)*

            1) read bytes from storage engine (STORAGE/INDEX TYPE) and send "decoded" field to mysql core (INTERNAL TYPE)
            2) read bytes from mysql core (INTERNAL TYPE) and send "encoded" bytes to storage engine (STORAGE/INDEX TYPE)
            3) compare values could/should/must be pass via PLUGIN, for example if we want a ENUM field plugin to use a external table as KEY(int)=>VALUE(string), we can call via PLUGIN interface, a select query to solve this, like:

            SELECT VALUE FROM TABLE WHERE VALUE="ID"
            UNION
            SELECT VALUE FROM TABLE WHERE KEY="ID"
            LIMIT 1

            4) optimize the "<field> <operator> <constant>" where operations

            there's some problems.... first one, user interfaces (heidisql for example) will not know what type of information it will have just read the CREATE TABLE
            we could add more information to "SHOW COLUMNS FROM <table>", example:
            || *Field* || *Type* || *Null* || *Key* || *Default* || *Extra* || *Internal Type* || *Storage Type* || *Index Type* ||
            | ID | PLUGIN('CRYPT','1','SHA1','PASSWORD=ABCEDFG,SIZE=255') | NO | | 0 | | VARCHAR(255) | BLOB | BLOB |


            more considerations about different versions of the same plugin:
            we could add a 'automatic' alter table, when one plugin is upgrade from version 1 to version 2 for example
            the plugin could read the old value, and write the new value, just an idea...
            rspadim roberto spadim made changes -
            Description This MDEV will allow a plugin for field types, there's many MDEV and ideas over mysql/mariadb/percona/others forks, that want IPv6, Encrypted column, and others features, this is nice, but add many non standard code (but native code), the idea is allow this to be a plugin, and not a native code.

            *THIS MDEV IS A RAW IDEA, and MUST BE CHECKED! the main high level idea is here, low level should be considered before start work*

            based on PostgrSQL definition "built-in general-purpose data types" is something that all MYSQL ENGINES know about field type, theses types is the current mysql types, and should be used by this field plugin.
            I WILL CALL IT AS "INTERNAL TYPE", TO STORAGE ENGINE I WILL CALL IT AS "STORAGE TYPE" AND FOR INDEX I WILL CALL IT AS "INDEX TYPE"

            ---

            for Alter table sintax we will have:
            {code}
            ALTER TABLE TABLE ...
            ADD field_name
            PLUGIN(<plugin info-1>,<plugin info-2>,<plugin info-3>,<plugin info-4>)
            NOT NULL/NULL
            AUTOINCREMENT
            DEFAULT
            ... others field parameters, the point here is only the FIELD TYPE,others parameters will exists, and will be used when possible, but plugin will return a error if it don't support for example a default value, or a not null, null or autoincrement
            {code}

            <plugin info> will be saved at .FRM file, and informations here are:
            #plugin name (same value of "SELECT PLUGIN_NAME FROM information_schema.PLUGINS")
            #plugin version (same value of "SELECT PLUGIN_VERSION FROM information_schema.PLUGINS")
            #plugin column type name (internal to plugin code)
            #plugin column options (internal to plugin code)

            The plugin will "calculate" the "INTERNAL TYPE", "STORAGE TYPE", "INDEX TYPE" to be used
            # We must check if we need a *STORAGE TYPE* and a "INDEX TYPE", based that some colations could be used, and some optimizations could be used, index could be encrypted or for example we could write a string to storage, and a integer to index, *must check if this is possible with today internal mysql code*

            This information will be added to SHOW COLUMN command

            the FRM file will store the "FIELD TYPE", "STORAGE TYPE", "INDEX TYPE", "INTERNAL TYPE"
            we must add a global variable, "open_table_without_field_plugin_definition" it have 3 values:
            0=> don't open, report an error
            1=> open, and report a warning
            2=> open and don't report anything
            check that (1 and 2) make the table READ ONLY !!!! *we can't WRITE without the plugin loaded!!!*

            Let'me explain with a example how the plugin parameters should be used:
            {code}
            PLUGIN(
             'CRYPT',
             '1',
             'SHA1',
             "PASSWORD=ABCDEFG,SIZE=255"
            )
            {code}
            this kind of plugin, with name "CRYPT", version "1", will use a "SHA1" column (maybe a algorithm to crypt/decrypt information from disk), with parameters about password and "INTERNAL TYPE"=varchar(255)

            internally plugin will have function to: *(must be better defined)*

            1) read bytes from storage engine (STORAGE/INDEX TYPE) and send "decoded" field to mysql core (INTERNAL TYPE)
            2) read bytes from mysql core (INTERNAL TYPE) and send "encoded" bytes to storage engine (STORAGE/INDEX TYPE)
            3) compare values could/should/must be pass via PLUGIN, for example if we want a ENUM field plugin to use a external table as KEY(int)=>VALUE(string), we can call via PLUGIN interface, a select query to solve this, like:

            SELECT VALUE FROM TABLE WHERE VALUE="ID"
            UNION
            SELECT VALUE FROM TABLE WHERE KEY="ID"
            LIMIT 1

            4) optimize the "<field> <operator> <constant>" where operations

            there's some problems.... first one, user interfaces (heidisql for example) will not know what type of information it will have just read the CREATE TABLE
            we could add more information to "SHOW COLUMNS FROM <table>", example:
            || *Field* || *Type* || *Null* || *Key* || *Default* || *Extra* || *Internal Type* || *Storage Type* || *Index Type* ||
            | ID | PLUGIN('CRYPT','1','SHA1','PASSWORD=ABCEDFG,SIZE=255') | NO | | 0 | | VARCHAR(255) | BLOB | BLOB |


            more considerations about different versions of the same plugin:
            we could add a 'automatic' alter table, when one plugin is upgrade from version 1 to version 2 for example
            the plugin could read the old value, and write the new value, just an idea...
            This MDEV will allow a plugin for field types, there's many MDEV and ideas over mysql/mariadb/percona/others forks, that want IPv6, Encrypted column, and others features, this is nice, but add many non standard code (but native code), the idea is allow this to be a plugin, and not a native code.

            *THIS MDEV IS A RAW IDEA, and MUST BE CHECKED! the main high level idea is here, low level should be considered before start work*

            based on PostgrSQL definition "built-in general-purpose data types" is something that all MYSQL ENGINES know about field type, theses types is the current mysql types, and should be used by this field plugin.
            I WILL CALL IT AS "INTERNAL TYPE", TO STORAGE ENGINE I WILL CALL IT AS "STORAGE TYPE" AND FOR INDEX I WILL CALL IT AS "INDEX TYPE"

            ---

            for Alter table sintax we will have:
            {code}
            ALTER TABLE TABLE ...
            ADD field_name
            PLUGIN(<plugin info-1>,<plugin info-2>,<plugin info-3>,<plugin info-4>)
            NOT NULL/NULL
            AUTOINCREMENT
            DEFAULT
            ... others field parameters
            {code}
            # the point here is only the FIELD TYPE, others parameters will exist, and will be used when possible, plugin will return a error if it don't support for example a default value, or a not null, null or autoincrement

            <plugin info> will be saved at .FRM file, and informations are:
            # plugin name (same value of "SELECT PLUGIN_NAME FROM information_schema.PLUGINS")
            # plugin version (same value of "SELECT PLUGIN_VERSION FROM information_schema.PLUGINS")
            # plugin column type name (internal to plugin code)
            # plugin column options (internal to plugin code)

            The plugin will "calculate" the "INTERNAL TYPE", "STORAGE TYPE", "INDEX TYPE" to be used
            # the FRM file will store the "FIELD TYPE", "STORAGE TYPE", "INDEX TYPE", "INTERNAL TYPE"
            # We must check if we need a *STORAGE TYPE* and a "INDEX TYPE", based that some colations could be used, and some optimizations could be used, index could be encrypted or for example we could write a string to storage, and a integer to index, *must check if this is possible with today internal mysql code*

            This information will be added to SHOW COLUMN command and others information_schemas tables

            we must add a global variable, "open_table_without_field_plugin_definition" it have 3 values:
            # don't open, report an error
            # open, and report a warning
            # open and don't report anything
            check that (1 and 2) make the table READ ONLY !!!! *we can't WRITE without the plugin loaded!!!*

            # POINT TO THINK* -> We can DUMP/RESTORE a table faster if we don't use the plugin interface, just the engine information, maybe a *DISABLE FIELD PLUGIN* before a DUMP/RESTORE could help a lot here, and allow a WRITE without using the plugin interface

            ---
            Let'me explain with a example how the plugin parameters should be used:
            {code}
            PLUGIN(
             'CRYPT',
             '1',
             'SHA1',
             "PASSWORD=ABCDEFG,SIZE=255"
            )
            {code}
            this kind of plugin, with name "CRYPT", version "1", will use a "SHA1" column (maybe a algorithm to crypt/decrypt information from disk), with parameters about password and size, the "INTERNAL TYPE" calculated will be a varchar(255), the storage type is a BLOB column, and the index type is a BLOB column too (check that some times we can use VARCHAR(255) since the index can't use BLOB, but a VARCHAR(255) is allowed... we could for example crypt the STORAGE and leave the index uncrypted... just a plugin feature but in this case a security problem)

            internally plugin will have function to: *(must be better defined)*

            # read bytes from storage engine (STORAGE/INDEX TYPE) and send "decoded" field to mysql core (INTERNAL TYPE)
            # read bytes from mysql core (INTERNAL TYPE) and send "encoded" bytes to storage engine (STORAGE/INDEX TYPE)
            # compare values could/should/must pass PLUGIN, for example if we want a EXTERNAL_ENUM field plugin to use a external table as KEY(int)=>VALUE(string), we can call via PLUGIN interface, for example
            PLUGIN('EXTERNAL_ENUM','1','KEY','DATABASE=some_database,TABLE=some_table,KEY=some_column,VALUE=some_column')
            and the plugin will execute a select query to solve the translation between INTERNAL and STORAGE TYPES, like:
            {code}
            SELECT VALUE FROM TABLE WHERE VALUE="ID"
            UNION
            SELECT VALUE FROM TABLE WHERE KEY="ID"
            LIMIT 1
            {code}
            # optimize the "<field> <operator> <constant>" where operations, here the EXTERNAL_ENUM could return ALWAYS FALSE, or ALWAYS TRUE

            there's some client side problems.... first one, user interfaces (heidisql for example) will not know what type of information it will have just reading the CREATE TABLE information
            we must add more information to "SHOW COLUMNS FROM <table>", example:
            || *Field* || *Type* || *Null* || *Key* || *Default* || *Extra* || *Internal Type* || *Storage Type* || *Index Type* ||
            | ID | PLUGIN('CRYPT','1','SHA1','PASSWORD=ABCEDFG,SIZE=255') | NO | | 0 | | VARCHAR(255) | BLOB | BLOB |

            *more considerations about different versions of the same plugin*
            we could add a 'automatic' alter table feature to upgrade a plugin field from version 1 to version 2 for example

            current field information:
            CREATE TABLE a (field PLUGIN('plugin','1','column','parameters'))
            new field information:
            ALTER TABLE a (field PLUGIN('plugin','2','column','parameters'))

            the plugin could read the old value, and write the new value, just an idea, the first problem here is the WRONG PLUGIN VERSION ERROR, we could read the METAINFORMATION (SHOW FIELD, SHOW CREATE TABLE), but we cant read the data (check "open_table_without_field_plugin_definition" variable), but in this case we can upgrade the field definition via alter table

            the plugin will return something like "don't change anything" or "must change table" or "can't upgrade table" to alter table command
            rspadim roberto spadim made changes -
            rspadim roberto spadim made changes -
            rspadim roberto spadim made changes -
            serg Sergei Golubchik made changes -
            Fix Version/s 10.1.0 [ 12200 ]
            rspadim roberto spadim made changes -
            serg Sergei Golubchik made changes -
            Labels gsoc14
            serg Sergei Golubchik made changes -
            serg Sergei Golubchik made changes -
            serg Sergei Golubchik made changes -
            Description This MDEV will allow a plugin for field types, there's many MDEV and ideas over mysql/mariadb/percona/others forks, that want IPv6, Encrypted column, and others features, this is nice, but add many non standard code (but native code), the idea is allow this to be a plugin, and not a native code.

            *THIS MDEV IS A RAW IDEA, and MUST BE CHECKED! the main high level idea is here, low level should be considered before start work*

            based on PostgrSQL definition "built-in general-purpose data types" is something that all MYSQL ENGINES know about field type, theses types is the current mysql types, and should be used by this field plugin.
            I WILL CALL IT AS "INTERNAL TYPE", TO STORAGE ENGINE I WILL CALL IT AS "STORAGE TYPE" AND FOR INDEX I WILL CALL IT AS "INDEX TYPE"

            ---

            for Alter table sintax we will have:
            {code}
            ALTER TABLE TABLE ...
            ADD field_name
            PLUGIN(<plugin info-1>,<plugin info-2>,<plugin info-3>,<plugin info-4>)
            NOT NULL/NULL
            AUTOINCREMENT
            DEFAULT
            ... others field parameters
            {code}
            # the point here is only the FIELD TYPE, others parameters will exist, and will be used when possible, plugin will return a error if it don't support for example a default value, or a not null, null or autoincrement

            <plugin info> will be saved at .FRM file, and informations are:
            # plugin name (same value of "SELECT PLUGIN_NAME FROM information_schema.PLUGINS")
            # plugin version (same value of "SELECT PLUGIN_VERSION FROM information_schema.PLUGINS")
            # plugin column type name (internal to plugin code)
            # plugin column options (internal to plugin code)

            The plugin will "calculate" the "INTERNAL TYPE", "STORAGE TYPE", "INDEX TYPE" to be used
            # the FRM file will store the "FIELD TYPE", "STORAGE TYPE", "INDEX TYPE", "INTERNAL TYPE"
            # We must check if we need a *STORAGE TYPE* and a "INDEX TYPE", based that some colations could be used, and some optimizations could be used, index could be encrypted or for example we could write a string to storage, and a integer to index, *must check if this is possible with today internal mysql code*

            This information will be added to SHOW COLUMN command and others information_schemas tables

            we must add a global variable, "open_table_without_field_plugin_definition" it have 3 values:
            # don't open, report an error
            # open, and report a warning
            # open and don't report anything
            check that (1 and 2) make the table READ ONLY !!!! *we can't WRITE without the plugin loaded!!!*

            # POINT TO THINK* -> We can DUMP/RESTORE a table faster if we don't use the plugin interface, just the engine information, maybe a *DISABLE FIELD PLUGIN* before a DUMP/RESTORE could help a lot here, and allow a WRITE without using the plugin interface

            ---
            Let'me explain with a example how the plugin parameters should be used:
            {code}
            PLUGIN(
             'CRYPT',
             '1',
             'SHA1',
             "PASSWORD=ABCDEFG,SIZE=255"
            )
            {code}
            this kind of plugin, with name "CRYPT", version "1", will use a "SHA1" column (maybe a algorithm to crypt/decrypt information from disk), with parameters about password and size, the "INTERNAL TYPE" calculated will be a varchar(255), the storage type is a BLOB column, and the index type is a BLOB column too (check that some times we can use VARCHAR(255) since the index can't use BLOB, but a VARCHAR(255) is allowed... we could for example crypt the STORAGE and leave the index uncrypted... just a plugin feature but in this case a security problem)

            internally plugin will have function to: *(must be better defined)*

            # read bytes from storage engine (STORAGE/INDEX TYPE) and send "decoded" field to mysql core (INTERNAL TYPE)
            # read bytes from mysql core (INTERNAL TYPE) and send "encoded" bytes to storage engine (STORAGE/INDEX TYPE)
            # compare values could/should/must pass PLUGIN, for example if we want a EXTERNAL_ENUM field plugin to use a external table as KEY(int)=>VALUE(string), we can call via PLUGIN interface, for example
            PLUGIN('EXTERNAL_ENUM','1','KEY','DATABASE=some_database,TABLE=some_table,KEY=some_column,VALUE=some_column')
            and the plugin will execute a select query to solve the translation between INTERNAL and STORAGE TYPES, like:
            {code}
            SELECT VALUE FROM TABLE WHERE VALUE="ID"
            UNION
            SELECT VALUE FROM TABLE WHERE KEY="ID"
            LIMIT 1
            {code}
            # optimize the "<field> <operator> <constant>" where operations, here the EXTERNAL_ENUM could return ALWAYS FALSE, or ALWAYS TRUE

            there's some client side problems.... first one, user interfaces (heidisql for example) will not know what type of information it will have just reading the CREATE TABLE information
            we must add more information to "SHOW COLUMNS FROM <table>", example:
            || *Field* || *Type* || *Null* || *Key* || *Default* || *Extra* || *Internal Type* || *Storage Type* || *Index Type* ||
            | ID | PLUGIN('CRYPT','1','SHA1','PASSWORD=ABCEDFG,SIZE=255') | NO | | 0 | | VARCHAR(255) | BLOB | BLOB |

            *more considerations about different versions of the same plugin*
            we could add a 'automatic' alter table feature to upgrade a plugin field from version 1 to version 2 for example

            current field information:
            CREATE TABLE a (field PLUGIN('plugin','1','column','parameters'))
            new field information:
            ALTER TABLE a (field PLUGIN('plugin','2','column','parameters'))

            the plugin could read the old value, and write the new value, just an idea, the first problem here is the WRONG PLUGIN VERSION ERROR, we could read the METAINFORMATION (SHOW FIELD, SHOW CREATE TABLE), but we cant read the data (check "open_table_without_field_plugin_definition" variable), but in this case we can upgrade the field definition via alter table

            the plugin will return something like "don't change anything" or "must change table" or "can't upgrade table" to alter table command
            Issues to solve:
            * read/write: that's easy, the plugin provides some kind of a "store" method that serializes the data into something that can be memcmp-ed. And "val" methods as appropriate.
            * indexing: not at issue, the engine thinks the column type is BINARY and indexes is accordingly
            * don't forget that field definition may use parameters, like in VARCHAR(10)
            * protocol
            ** text protocol - what to send as field metadata? variant: MYSQL_TYPE_PLUGIN and a string with the type name
            ** binary protocol - how to send the value to the client: variant: as a string. how the client send the value to the server? either way, the server converts it from number/string/etc just as for INSERTs
            * replication, RBR
            ** similar, use MYSQL_TYPE_PLUGIN, and as additional metadata - field type as a string, parameters, whatever

            So, a plugin would need to provide
            * store() method from at least some of the basic types
            * val() methods to at least some of the basic types
            * description of whatever parameters a field definition takes
            * informational methods, like store_length(), etc
            serg Sergei Golubchik made changes -
            Description Issues to solve:
            * read/write: that's easy, the plugin provides some kind of a "store" method that serializes the data into something that can be memcmp-ed. And "val" methods as appropriate.
            * indexing: not at issue, the engine thinks the column type is BINARY and indexes is accordingly
            * don't forget that field definition may use parameters, like in VARCHAR(10)
            * protocol
            ** text protocol - what to send as field metadata? variant: MYSQL_TYPE_PLUGIN and a string with the type name
            ** binary protocol - how to send the value to the client: variant: as a string. how the client send the value to the server? either way, the server converts it from number/string/etc just as for INSERTs
            * replication, RBR
            ** similar, use MYSQL_TYPE_PLUGIN, and as additional metadata - field type as a string, parameters, whatever

            So, a plugin would need to provide
            * store() method from at least some of the basic types
            * val() methods to at least some of the basic types
            * description of whatever parameters a field definition takes
            * informational methods, like store_length(), etc
            Issues to solve:
            * read/write: that's easy, the plugin provides some kind of a "store" method that serializes the data into something that can be memcmp-ed. And "val" methods as appropriate.
            * indexing: not at issue, the engine thinks the column type is BINARY and indexes is accordingly
            * don't forget that field definition may use parameters, like in VARCHAR(10)
            * protocol
            ** text protocol - what to send as field metadata? variant: MYSQL_TYPE_PLUGIN and a string with the type name
            ** binary protocol - how to send the value to the client: variant: as a string. how the client send the value to the server? either way, the server converts it from number/string/etc just as for INSERTs
            * replication, RBR
            ** similar, use MYSQL_TYPE_PLUGIN, and as additional metadata - field type as a string, parameters, whatever

            So, a plugin would need to provide
            * store() method from at least some of the basic types
            * val() methods to at least some of the basic types
            * description of whatever parameters a field definition takes
            * informational methods, like store_length(), etc

            _see the original issue description in the history_
            serg Sergei Golubchik made changes -
            Description Issues to solve:
            * read/write: that's easy, the plugin provides some kind of a "store" method that serializes the data into something that can be memcmp-ed. And "val" methods as appropriate.
            * indexing: not at issue, the engine thinks the column type is BINARY and indexes is accordingly
            * don't forget that field definition may use parameters, like in VARCHAR(10)
            * protocol
            ** text protocol - what to send as field metadata? variant: MYSQL_TYPE_PLUGIN and a string with the type name
            ** binary protocol - how to send the value to the client: variant: as a string. how the client send the value to the server? either way, the server converts it from number/string/etc just as for INSERTs
            * replication, RBR
            ** similar, use MYSQL_TYPE_PLUGIN, and as additional metadata - field type as a string, parameters, whatever

            So, a plugin would need to provide
            * store() method from at least some of the basic types
            * val() methods to at least some of the basic types
            * description of whatever parameters a field definition takes
            * informational methods, like store_length(), etc

            _see the original issue description in the history_
            Issues to solve:
            * read/write: that's easy, the plugin provides some kind of a "store" method that serializes the data into something that can be memcmp-ed. And "val" methods as appropriate.
            * indexing: not at issue, the engine thinks the column type is BINARY and indexes is accordingly
            * don't forget that field definition may use parameters, like in VARCHAR(10)
            * protocol
            ** text protocol - what to send as field metadata? variant: MYSQL_TYPE_PLUGIN and a string with the type name
            ** binary protocol - how to send the value to the client: variant: as a string. how the client send the value to the server? either way, the server converts it from number/string/etc just as for INSERTs
            * replication, RBR
            ** similar, use MYSQL_TYPE_PLUGIN, and as additional metadata - field type as a string, parameters, whatever

            So, a plugin would need to provide
            * store() method from at least some of the basic types
            * val() methods to at least some of the basic types
            * description of whatever parameters a field definition takes
            * informational methods, like store_length(), etc

            *This task doesn't cover everything!* It is assumed that we can expand this API later to add more features. In particular, the following is not solved:
            * data types that cannot be efficiently memcmp()'ed. For example, this proposal doesn't allow to implement a string type with charset support.
            * data types that require special indexes, such as XML, spatial data, etc.

            _see the original issue description in the history_
            serg Sergei Golubchik made changes -
            Description Issues to solve:
            * read/write: that's easy, the plugin provides some kind of a "store" method that serializes the data into something that can be memcmp-ed. And "val" methods as appropriate.
            * indexing: not at issue, the engine thinks the column type is BINARY and indexes is accordingly
            * don't forget that field definition may use parameters, like in VARCHAR(10)
            * protocol
            ** text protocol - what to send as field metadata? variant: MYSQL_TYPE_PLUGIN and a string with the type name
            ** binary protocol - how to send the value to the client: variant: as a string. how the client send the value to the server? either way, the server converts it from number/string/etc just as for INSERTs
            * replication, RBR
            ** similar, use MYSQL_TYPE_PLUGIN, and as additional metadata - field type as a string, parameters, whatever

            So, a plugin would need to provide
            * store() method from at least some of the basic types
            * val() methods to at least some of the basic types
            * description of whatever parameters a field definition takes
            * informational methods, like store_length(), etc

            *This task doesn't cover everything!* It is assumed that we can expand this API later to add more features. In particular, the following is not solved:
            * data types that cannot be efficiently memcmp()'ed. For example, this proposal doesn't allow to implement a string type with charset support.
            * data types that require special indexes, such as XML, spatial data, etc.

            _see the original issue description in the history_
            Issues to solve:
            * read/write: that's easy, the plugin provides some kind of a "store" method that serializes the data into something that can be memcmp-ed. And "val" methods as appropriate.
            * indexing: not at issue, the engine thinks the column type is BINARY and indexes is accordingly
            * don't forget that field definition may use parameters, like in VARCHAR(10)
            * protocol
            ** text protocol - what to send as field metadata? variant: MYSQL_TYPE_PLUGIN and a string with the type name
            ** binary protocol - how to send the value to the client: variant: as a string. how the client send the value to the server? either way, the server converts it from number/string/etc just as for INSERTs
            * replication, RBR
            ** similar, use MYSQL_TYPE_PLUGIN, and as additional metadata - field type as a string, parameters, whatever

            So, a plugin would need to provide
            * store() method from at least some of the basic types
            * val() methods to at least some of the basic types
            * description of whatever parameters a field definition takes
            * informational methods, like store_length(), etc

            *This task doesn't cover everything!* It is assumed that we can expand this API later to add more features. In particular, the following is not solved:
            * data types that cannot be efficiently memcmp()'ed. For example, this proposal doesn't allow to implement a string type with charset support.
            * data types that require special indexes, such as XML, spatial data, etc.

            _see also the original issue description in the history_
            serg Sergei Golubchik made changes -
            Assignee Alexander Barkov [ bar ]
            dbart Daniel Bartholomew made changes -
            Fix Version/s 10.1.1 [ 16100 ]
            Fix Version/s 10.1.0 [ 12200 ]
            serg Sergei Golubchik made changes -
            Workflow defaullt [ 28427 ] MariaDB v2 [ 43674 ]
            serg Sergei Golubchik made changes -
            Priority Major [ 3 ] Minor [ 4 ]
            bar Alexander Barkov made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            serg Sergei Golubchik made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            ratzpo Rasmus Johansson (Inactive) made changes -
            Workflow MariaDB v2 [ 43674 ] MariaDB v3 [ 67312 ]
            serg Sergei Golubchik made changes -
            Fix Version/s 10.2 [ 14601 ]
            Fix Version/s 10.1 [ 16100 ]
            bar Alexander Barkov made changes -
            Labels gsoc14
            serg Sergei Golubchik made changes -
            Labels gsoc14
            serg Sergei Golubchik made changes -
            serg Sergei Golubchik made changes -
            serg Sergei Golubchik made changes -
            serg Sergei Golubchik made changes -
            serg Sergei Golubchik made changes -
            serg Sergei Golubchik made changes -
            serg Sergei Golubchik made changes -
            ratzpo Rasmus Johansson (Inactive) made changes -
            Sprint 10.2.0-1 [ 21 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Rank Ranked lower
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            ratzpo Rasmus Johansson (Inactive) made changes -
            Sprint 10.2.0-1 [ 21 ] 10.2.0-1, 5.5.47-1 [ 21, 22 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Rank Ranked higher
            ratzpo Rasmus Johansson (Inactive) made changes -
            Sprint 10.2.0-1, 5.5.47-1 [ 21, 22 ] 10.2.0-1 [ 21 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Rank Ranked lower
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            ratzpo Rasmus Johansson (Inactive) made changes -
            Sprint 10.2.0-1 [ 21 ] 10.2.0-1, 10.2.0-2 [ 21, 26 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Rank Ranked lower
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            ratzpo Rasmus Johansson (Inactive) made changes -
            Rank Ranked higher
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            ratzpo Rasmus Johansson (Inactive) made changes -
            Sprint 10.2.0-1, 10.2.0-2 [ 21, 26 ] 10.2.0-1, 10.2.0-2, 10.2.0-4 [ 21, 26, 29 ]
            bar Alexander Barkov made changes -
            serg Sergei Golubchik made changes -
            serg Sergei Golubchik made changes -
            serg Sergei Golubchik made changes -
            bar Alexander Barkov made changes -
            ratzpo Rasmus Johansson (Inactive) made changes -
            Rank Ranked higher
            bar Alexander Barkov made changes -
            ratzpo Rasmus Johansson (Inactive) made changes -
            Sprint 10.2.0-1, 10.2.0-2, 10.2.0-4 [ 21, 26, 29 ] 10.2.0-1, 10.2.0-2, 10.2.0-4, 10.2.0-5 [ 21, 26, 29, 32 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Rank Ranked lower
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            serg Sergei Golubchik made changes -
            serg Sergei Golubchik made changes -
            serg Sergei Golubchik made changes -
            serg Sergei Golubchik made changes -
            colin Colin Charles made changes -
            Labels gsoc14 gsoc14 gsoc16
            serg Sergei Golubchik made changes -
            Labels gsoc14 gsoc16 gsoc14
            bar Alexander Barkov made changes -
            Assignee Alexander Barkov [ bar ] Sergei Golubchik [ serg ]
            Status In Progress [ 3 ] In Review [ 10002 ]
            bar Alexander Barkov made changes -
            Sprint 10.2.0-1, 10.2.0-2, 10.2.0-4, 10.2.0-5 [ 21, 26, 29, 32 ] 10.2.0-1, 10.2.0-2, 10.2.0-4, 10.2.0-5, 10.2.0-6 [ 21, 26, 29, 32, 37 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Sprint 10.2.0-1, 10.2.0-2, 10.2.0-4, 10.2.0-5, 10.2.0-6 [ 21, 26, 29, 32, 37 ] 10.2.0-1, 10.2.0-2, 10.2.0-4, 10.2.0-5, 10.2.0-6, 10.2.0-7 [ 21, 26, 29, 32, 37, 39 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Rank Ranked lower
            ratzpo Rasmus Johansson (Inactive) made changes -
            Sprint 10.2.0-1, 10.2.0-2, 10.2.0-4, 10.2.0-5, 10.2.0-6, 10.2.0-7 [ 21, 26, 29, 32, 37, 39 ] 10.2.0-1, 10.2.0-2, 10.2.0-4, 10.2.0-5, 10.2.0-6, 10.2.0-7, 10.2.0-8 [ 21, 26, 29, 32, 37, 39, 41 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Rank Ranked lower
            bar Alexander Barkov made changes -
            serg Sergei Golubchik made changes -
            serg Sergei Golubchik made changes -
            ratzpo Rasmus Johansson (Inactive) made changes -
            Sprint 10.2.0-1, 10.2.0-2, 10.2.0-4, 10.2.0-5, 10.2.0-6, 10.2.0-7, 10.2.0-8 [ 21, 26, 29, 32, 37, 39, 41 ] 10.2.0-1, 10.2.0-2, 10.2.0-4, 10.2.0-5, 10.2.0-6, 10.2.0-7, 10.2.0-8, 10.2.1-1 [ 21, 26, 29, 32, 37, 39, 41, 56 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Rank Ranked higher
            ratzpo Rasmus Johansson (Inactive) made changes -
            Sprint 10.2.0-1, 10.2.0-2, 10.2.0-4, 10.2.0-5, 10.2.0-6, 10.2.0-7, 10.2.0-8, 10.2.1-1 [ 21, 26, 29, 32, 37, 39, 41, 56 ] 10.2.0-1, 10.2.0-2, 10.2.0-4, 10.2.0-5, 10.2.0-6, 10.2.0-7, 10.2.0-8, 10.2.1-1, 10.2.1-2 [ 21, 26, 29, 32, 37, 39, 41, 56, 63 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Sprint 10.2.0-1, 10.2.0-2, 10.2.0-4, 10.2.0-5, 10.2.0-6, 10.2.0-7, 10.2.0-8, 10.2.1-1, 10.2.1-2 [ 21, 26, 29, 32, 37, 39, 41, 56, 63 ] 10.2.0-1, 10.2.0-2, 10.2.0-4, 10.2.0-5, 10.2.0-6, 10.2.0-7, 10.2.0-8, 10.2.1-1, 10.2.1-3 [ 21, 26, 29, 32, 37, 39, 41, 56, 65 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Rank Ranked higher
            ratzpo Rasmus Johansson (Inactive) made changes -
            Sprint 10.2.0-1, 10.2.0-2, 10.2.0-4, 10.2.0-5, 10.2.0-6, 10.2.0-7, 10.2.0-8, 10.2.1-1, 10.2.1-3 [ 21, 26, 29, 32, 37, 39, 41, 56, 65 ] 10.2.0-1, 10.2.0-2, 10.2.0-4, 10.2.0-5, 10.2.0-6, 10.2.0-7, 10.2.0-8, 10.2.1-1, 10.2.1-3, 10.2.1-4 [ 21, 26, 29, 32, 37, 39, 41, 56, 65, 66 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Sprint 10.2.0-1, 10.2.0-2, 10.2.0-4, 10.2.0-5, 10.2.0-6, 10.2.0-7, 10.2.0-8, 10.2.1-1, 10.2.1-3, 10.2.1-4 [ 21, 26, 29, 32, 37, 39, 41, 56, 65, 66 ] 10.2.0-1, 10.2.0-2, 10.2.0-4, 10.2.0-5, 10.2.0-6, 10.2.0-7, 10.2.0-8, 10.2.1-1, 10.2.1-3, 10.2.1-4, 10.2.1-5 [ 21, 26, 29, 32, 37, 39, 41, 56, 65, 66, 68 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Sprint 10.2.0-1, 10.2.0-2, 10.2.0-4, 10.2.0-5, 10.2.0-6, 10.2.0-7, 10.2.0-8, 10.2.1-1, 10.2.1-3, 10.2.1-4, 10.2.1-5 [ 21, 26, 29, 32, 37, 39, 41, 56, 65, 66, 68 ] 10.2.0-1, 10.2.0-2, 10.2.0-4, 10.2.0-5, 10.2.0-6, 10.2.0-7, 10.2.0-8, 10.2.1-1, 10.2.1-3, 10.2.1-4, 10.2.1-5, 10.2.2-3 [ 21, 26, 29, 32, 37, 39, 41, 56, 65, 66, 68, 83 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Rank Ranked lower
            serg Sergei Golubchik made changes -
            Fix Version/s 10.2 [ 14601 ]
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            Assignee Sergei Golubchik [ serg ] Alexander Barkov [ bar ]
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            Status In Review [ 10002 ] Stalled [ 10000 ]
            bar Alexander Barkov made changes -
            Status Stalled [ 10000 ] In Progress [ 3 ]
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            danblack Daniel Black made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            serg Sergei Golubchik made changes -
            serg Sergei Golubchik made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            ratzpo Rasmus Johansson (Inactive) made changes -
            Sprint 10.2.0-1, 10.2.0-2, 10.2.0-4, 10.2.0-5, 10.2.0-6, 10.2.0-7, 10.2.0-8, 10.2.1-1, 10.2.1-3, 10.2.1-4, 10.2.1-5, 10.2.2-3 [ 21, 26, 29, 32, 37, 39, 41, 56, 65, 66, 68, 83 ] 10.2.0-1, 10.2.0-2, 10.2.0-4, 10.2.0-5, 10.2.0-6, 10.2.0-7, 10.2.0-8, 10.2.1-1, 10.2.1-3, 10.2.1-4, 10.2.1-5, 10.2.2-3, 10.3.1-1 [ 21, 26, 29, 32, 37, 39, 41, 56, 65, 66, 68, 83, 164 ]
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            serg Sergei Golubchik made changes -
            serg Sergei Golubchik made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            julien.fritsch Julien Fritsch made changes -
            Issue Type Task [ 3 ] Epic [ 5 ]
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            Fix Version/s 10.5 [ 23123 ]
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            maxmether Max Mether made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            julien.fritsch Julien Fritsch made changes -
            Epic Name Add a plugin to field types (column types)
            julien.fritsch Julien Fritsch made changes -
            Summary Add a plugin to field types (column types) Data type plugin API version 1
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            julien.fritsch Julien Fritsch made changes -
            bar Alexander Barkov made changes -

            There is no a separate patch for MDEV-4912. This task consists of all other tasks marked as blockers for MDEV-4912.

            bar Alexander Barkov added a comment - There is no a separate patch for MDEV-4912 . This task consists of all other tasks marked as blockers for MDEV-4912 .
            bar Alexander Barkov made changes -
            Component/s Data types [ 13906 ]
            Fix Version/s 10.5.0 [ 23709 ]
            Fix Version/s 10.5 [ 23123 ]
            Resolution Fixed [ 1 ]
            Status In Progress [ 3 ] Closed [ 6 ]
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            serg Sergei Golubchik made changes -
            Workflow MariaDB v3 [ 67312 ] MariaDB v4 [ 146953 ]
            julien.fritsch Julien Fritsch made changes -
            Priority Minor [ 4 ] Major [ 3 ]
            julien.fritsch Julien Fritsch made changes -
            Priority Minor [ 4 ] Major [ 3 ]
            julien.fritsch Julien Fritsch made changes -
            Comment [ A comment with security level 'Developers' was removed. ]
            julien.fritsch Julien Fritsch made changes -
            Comment [ A comment with security level 'Developers' was removed. ]
            julien.fritsch Julien Fritsch made changes -
            Priority Major [ 3 ] Minor [ 4 ]

            People

              bar Alexander Barkov
              rspadim roberto spadim
              Votes:
              16 Vote for this issue
              Watchers:
              22 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.