Details
-
Task
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
None
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
- blocks
-
MDEV-4912 Data type plugin API version 1
- Closed
-
MDEV-20841 Turn GIS implementation into a plugin
- Open
- is blocked by
-
MDEV-20052 Add a MEM_ROOT pointer argument to Type_handler::make_xxx_field()
- Closed
-
MDEV-20721 Implement sql_type() for Field_real and Field_int
- Closed
-
MDEV-20734 Allow reserved keywords as user defined type names
- Closed
- relates to
-
MDEV-4912 Data type plugin API version 1
- Closed