Details

      Description

      Let's add a new plugin type: MariaDB_DATA_TYPE_PLUGIN.

      plugin->data of such plugin will point to a single Type_handler implementation. So looking up a pluggable data type by name should be done very easy, by this code block:

        if ((plugin= my_plugin_lock_by_name(thd, &name, MariaDB_DATA_TYPE_PLUGIN)))
        {
          /*
            INSTALL PLUGIN is not fully supported for data type plugins yet.
            Fow now we have only mandatory built-in plugins
            and dynamic plugins for test purposes,
            Should be safe to unlock the plugin immediately.
          */
          const Type_handler *ph= reinterpret_cast<const Type_handler*>
                                  (plugin_ref_to_int(plugin)->data);
          plugin_unlock(thd, plugin);
          return ph;
        }
      
      

      Note, as the above comment states, for now we assume we have:

      • mandatory built-in plugins
      • dynamic test plugins, used by MTR in a single-thread environment
        so locking (incrementing and decrementing use count) is out of scope of this task and will be done separately.

      Under terms of this task let's implement a simple test plugin implementing an alias for an existing data type, to demonstrate that the plugin data type is understood in various contexts:

      • CREATE TABLE t1 (a XXX)
      • CAST(expr AS XXX)
      • CREATE FUNCTION f1() RETURNS XXX
      • DECLARE a XXX; – SP variable declarations

        Attachments

          Issue Links

            Activity

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: