Details
-
Epic
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
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
- blocks
-
MDEV-274 The data type for IPv6/IPv4 addresses in MariaDB
-
- Closed
-
-
MDEV-4913 External ENUM Field definition
-
- Open
-
-
MDEV-4958 Adding datatype UUID
-
- Closed
-
-
MDEV-10018 Timestamp with time zone
-
- Open
-
-
MDEV-10575 sql_mode=ORACLE: Date and timestamp formats
-
- Open
-
-
MDEV-10592 sql_mode=ORACLE: TYPE .. TABLE OF for scalar data types
-
- Open
-
-
MDEV-10593 sql_mode=ORACLE: TYPE .. AS OBJECT: basic functionality
-
- Open
-
-
MDEV-11058 Put user defined exceptions to the same name space with variables
-
- Open
-
-
MDEV-11829 Please add support for datetime with time zone literals (ISO 8601)
-
- Open
-
-
MDEV-12252 ROW data type for stored function return values
-
- Closed
-
-
MDEV-12307 ROW data type for built-in function return values
-
- Stalled
-
-
MDEV-12308 Accessing ROW type function fields
-
- Open
-
-
MDEV-12513 INTERVAL data type
-
- Open
-
-
MDEV-12786 Feature Request : New Column Type Apt Version
-
- Open
-
- duplicates
-
MDEV-7931 Custom types support through extensions
-
- Closed
-
- is blocked by
-
MDEV-7199 Introduce the concept of data type handlers
-
- Closed
-
-
MDEV-8092 Change Column_definition::field_name from "const char *" to LEX_CSTRING
-
- Closed
-
-
MDEV-9170 Get rid of LEX::length and LEX::dec
-
- Closed
-
-
MDEV-9188 Split Column_definition::check() into virtual methods in Type_handler
-
- Closed
-
-
MDEV-9211 Split Column_definition::init_for_tmp_table, item_sum.cc:calc_tmp_field_type() into methods in Type_handler
-
- Closed
-
-
MDEV-9215 Detect cmp_type() and result_type() from field_type()
-
- Closed
-
-
MDEV-9216 Split field.cc:make_field() into virtual methods in Type_handler
-
- Closed
-
-
MDEV-9217 Split Item::tmp_table_field_from_field_type() into virtual methods in Type_handler
-
- Closed
-
-
MDEV-9218 Add a helper class Record_addr
-
- Closed
-
-
MDEV-9220 Split filesort.cc:make_sortkey() and filesort.cc::sortlength() into virtual methods in Type_handler
-
- Closed
-
-
MDEV-9221 Derive Item from Type_handler virtually
-
- Closed
-
-
MDEV-9234 Add Type_handler::union_element_finalize()
-
- Closed
-
-
MDEV-9235 Add Type_handler::is_param_long_data_type()
-
- Closed
-
-
MDEV-9238 Wrap create_virtual_tmp_table() into a class, split into different steps
-
- Closed
-
-
MDEV-9316 Add Field::store_hex_hybrid()
-
- Closed
-
-
MDEV-9319 ALTER from a bigger to a smaller blob type truncates too much data
-
- Closed
-
-
MDEV-9326 Split field_conv_incompatible() into methods in Field
-
- Closed
-
-
MDEV-9327 Split memcpy_field_possible() into virtual methods in Field
-
- Closed
-
-
MDEV-9334 ALTER from DECIMAL to BIGINT UNSIGNED returns a wrong result
-
- Closed
-
-
MDEV-9337 ALTER from DECIMAL and INT to DATETIME returns a wrong result
-
- Closed
-
-
MDEV-9340 Copying from INT/DOUBLE to ENUM is inconsistent
-
- Closed
-
-
MDEV-9391 InnoDB does not produce warnings when doing WHERE int_column=varchar_column
-
- Closed
-
-
MDEV-9392 Copying from DECIMAL to YEAR is not consistent about warnings
-
- Closed
-
-
MDEV-9393 Split Copy_field::get_copy_func() into virtual methods in Field
-
- Closed
-
-
MDEV-9395 Add Type_handler::Item_decimal_scale() and Item_divisor_precision_increment()
-
- Closed
-
-
MDEV-9396 Split Create_field::init() into virtual methods in Type_handler
-
- Closed
-
-
MDEV-9397 Split field.cc:calc_pack_length() into virtual methods in Type_handler
-
- Closed
-
-
MDEV-9398 Add Type_handler::cast_to_int_type
-
- Closed
-
-
MDEV-9406 CREATE TABLE..SELECT creates different columns for IFNULL() and equivalent COALESCE,CASE,IF
-
- Closed
-
-
MDEV-9407 Illegal mix of collation when using GROUP_CONCAT in a VIEW
-
- Closed
-
-
MDEV-9408 CREATE TABLE SELECT MAX(int_column) creates different columns for table vs view
-
- Closed
-
-
MDEV-9410 VIEW over a ROLLUP query reports too large columns
-
- Closed
-
-
MDEV-9495 Wrong field type for a UNION of a signed and an unsigned INT expression
-
- Closed
-
-
MDEV-9497 UNION and COALESCE produce different field types for DECIMAL+INT
-
- Closed
-
-
MDEV-9522 Split sql_select.cc:can_change_cond_ref_to_const into virtual methods in Type_handler
-
- Closed
-
-
MDEV-10309 COALESCE(12345678900) makes a column of a wrong type and truncates the data
-
- Closed
-
-
MDEV-10811 Change design from "Item is Type_handler" to "Item has Type_handler"
-
- Closed
-
-
MDEV-11245 Move prepare_create_field and sp_prepare_create_field() as methods to Column_definition
-
- Closed
-
-
MDEV-11294 Move definitions of Derivation, DTCollation, Type_std_attributes from field.h and item.h to sql_type.h
-
- Closed
-
-
MDEV-11298 Split Item_func_hex::val_str_ascii() into virtual methods in Type_handler
-
- Closed
-
-
MDEV-11302 Add class Type_ext_attributes and Type_handler::join_type_ext_attributes()
-
- Closed
-
-
MDEV-11330 Split Item_func_hybrid_field_type::val_xxx() into methods in Type_handler
-
- Closed
-
-
MDEV-11331 Wrong result for INSERT INTO t1 (datetime_field) VALUES (hybrid_function_of_TIME_data_type)
-
- Closed
-
-
MDEV-11333 Expect "Impossible where condition" for WHERE timestamp_field>=DATE_ADD(TIMESTAMP'9999-01-01 00:00:00',INTERVAL 1000 YEAR)
-
- Closed
-
-
MDEV-11337 Split Item::save_in_field() into virtual methods in Type_handler
-
- Closed
-
-
MDEV-11344 Split Arg_comparator::set_compare_func() into virtual methods in Type_handler
-
- Closed
-
-
MDEV-11357 Split Item_cache::get_cache() into virtual methods in Type_handler
-
- Closed
-
-
MDEV-11365 Split the data type and attribute related code in Item_sum_hybrid::fix_fields into Type_handler::Item_sum_hybrid_fix_length_and_dec()
-
- Closed
-
-
MDEV-11478 Result data type aggregation for pluggable data types
-
- Closed
-
-
MDEV-11482 Incorrect result for (time_expr BETWEEN timestamp_exp1 AND timestamp_expr2)
-
- Closed
-
-
MDEV-11485 Split Item_func_between::val_int() into virtual methods in Type_handler
-
- Closed
-
-
MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
-
- Closed
-
-
MDEV-11503 Introduce Type_handler::make_in_vector() and Item_func_in_fix_comparator_compatible_types()
-
- Closed
-
-
MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
-
- Closed
-
-
MDEV-11528 Split Item_func_min_max::val_xxx() and Item_func_min_max::get_date() into methods in Type_handler
-
- Closed
-
-
MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
-
- Closed
-
-
MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
-
- Closed
-
-
MDEV-11558 Split Item_type_holder::display_length into virtual methods in Type_handler
-
- Closed
-
-
MDEV-11615 Split Item_hybrid_func::fix_attributes into virtual methods in Type_handler
-
- Closed
-
-
MDEV-11672 mysql_list_field() returns wrong default values for VIEW
-
- Closed
-
-
MDEV-11692 Comparison data type aggregation for pluggable data types
-
- Closed
-
-
MDEV-11815 SP variables of temporal data types do not replicate correctly
-
- Closed
-
-
MDEV-11913 Split sp_get_item_value() into methods in Type_handler
-
- Closed
-
-
MDEV-12001 Split Item_func_round::fix_length_and_dec to virtual methods in Type_handler
-
- Closed
-
-
MDEV-12199 Split Item_func_{abs|neg|int_val}::fix_length_and_dec() into methods in Type_handler
-
- Closed
-
-
MDEV-12238 Add Type_handler::Item_func_{plus|minus|mul|div|mod}_fix_length_and_dec()
-
- Closed
-
-
MDEV-12239 Add Type_handler::Item_sum_{sum|avg|variance}_fix_length_and_dec()
-
- Closed
-
-
MDEV-12303 Add Type_handler::Item_xxx_fix_length_and_dec() for CAST classes
-
- Closed
-
-
MDEV-12338 Split Item_type_holder::get_real_type() into virtual Item::real_type_handler()
-
- Closed
-
-
MDEV-12426 Add Field::type_handler()
-
- Closed
-
-
MDEV-12497 Wrong data type for LEAST(latin1_expr, utf8_expr)
-
- Closed
-
-
MDEV-12504 Wrong data type for LEAST(date_expr,time_expr)
-
- Closed
-
-
MDEV-12506 Split Item_func_min_max::fix_length_and_dec() into methods in Type_handler
-
- Closed
-
-
MDEV-12514 Split Item_temporal_func::fix_length_and_dec()
-
- Closed
-
-
MDEV-12546 Wrong metadata or data type for string user variables
-
- Closed
-
-
MDEV-12559 Split Item::temporal_precision() into virtual methods in Type_handler
-
- Closed
-
-
MDEV-12560 Wrong data type for SELECT NULL UNION SELECT Point(1,1)
-
- Closed
-
-
MDEV-12568 Add Type_handler::subquery_type_allows_materialization()
-
- Closed
-
-
MDEV-12574 MAX(old_decimal) produces a column of the old DECIMAL type
-
- Closed
-
-
MDEV-12582 Wrong data type for CREATE..SELECT MAX(COALESCE(timestamp_column))
-
- Closed
-
-
MDEV-12588 Add Type_handler::type_handler_for_tmp_table() and Type_handler::type_handler_for_union()
-
- Closed
-
-
MDEV-12594 UNION between fixed length double columns does not always preserve scale
-
- Closed
-
-
MDEV-12595 UNION converts INT to BIGINT
-
- Closed
-
-
MDEV-12599 UNION is not symmetric when mixing INT and CHAR
-
- Closed
-
-
MDEV-12601 Hybrid functions create a column of an impossible type DOUBLE(256,4)
-
- Closed
-
-
MDEV-12607 Hybrid functions create wrong VARBINARY length when mixing character and binary data
-
- Closed
-
-
MDEV-12617 CASE and CASE-alike hybrid functions do not preserve exact data types
-
- Closed
-
-
MDEV-12619 UNION creates excessive integer column types for integer literals
-
- Closed
-
-
MDEV-12649 Add Type_handler::Item_save_in_value
-
- Closed
-
-
MDEV-12655 Move Item_func::count_xxx_length() to Type_std_attributes
-
- Closed
-
-
MDEV-12665 Hybrid functions do not preserve geometry type
-
- Closed
-
-
MDEV-12687 Split Item::send() into virtual method in Type_handler
-
- Closed
-
-
MDEV-12692 Split Item_func_between::fix_length_and_dec
-
- Closed
-
-
MDEV-12695 Add Column_definition::type_handler()
-
- Closed
-
-
MDEV-12707 Split resolve_const_item() into virtual methods in Type_handler
-
- Closed
-
-
MDEV-12710 Fix Item_cache constructors to accept Type_handler instead of enum_field_types
-
- Closed
-
-
MDEV-12713 Define virtual type_handler() for all Item classes
-
- Closed
-
-
MDEV-12714 Determine Item::field_type() from Item::type_handler()
-
- Closed
-
-
MDEV-12716 Change Value_source::Context to operate Type_handler rather than Item_result
-
- Closed
-
-
MDEV-12717 Change Item_equal to operate Type_handler rather than Item_result
-
- Closed
-
-
MDEV-12718 Determine Item::cmp_type() from Item::type_handler()
-
- Closed
-
-
MDEV-12719 Determine Item::result_type() from Item::type_handler()
-
- Closed
-
-
MDEV-12721 Wrong execution plan for WHERE (date_field <=> timestamp_expr AND TRUE)
-
- Closed
-
-
MDEV-12769 Arithmetic operators with temporal types create excessive column types
-
- Closed
-
-
MDEV-12770 Add Type_handler::decimal_precision()
-
- Closed
-
-
MDEV-12772 Add Field::get_typelib() and Item::get_typelib()
-
- Closed
-
-
MDEV-12775 Reuse data type aggregation code for hybrid functions and UNION
-
- Closed
-
-
MDEV-12777 Change Lex_field_type_st::m_type from enum_field_types to Type_handler pointer
-
- Closed
-
-
MDEV-12798 Item_param does not preserve exact field type in EXECUTE IMMEDIATE 'CREATE TABLE AS SELECT ?' USING POINT(1,1)
-
- Closed
-
-
MDEV-12803 Improve function parameter data type control
-
- Closed
-
-
MDEV-12809 Bad column type created for TEXT(1431655798) CHARACTER SET utf8
-
- Closed
-
-
MDEV-12826 Add Type_handler::val_int_signed_typecast() and Type_handler::val_int_unsigned_typecast()
-
- Closed
-
-
MDEV-12833 Split Column_definition::create_length_to_internal_length() to virtual methods in Type_handler
-
- Closed
-
-
MDEV-12849 Out-of-range errors when casting hex-hybrid to SIGNED and UNSIGNED
-
- Closed
-
-
MDEV-12853 Out-of-range errors when CAST('-1' AS UNSIGNED)
-
- Closed
-
-
MDEV-12854 Synchronize CREATE..SELECT data type and result set metadata data type for INT functions
-
- Closed
-
-
MDEV-12856 Wrong result set metadata for DIV
-
- Closed
-
-
MDEV-12857 Out-of-range errors on CREATE..SELECT 2222222222 DIV 1
-
- Closed
-
-
MDEV-12858 Out-of-range error for CREATE..SELECT unsigned_int_column+1
-
- Closed
-
-
MDEV-12859 Out-of-range error for CREATE..SELECT @a:=EXTRACT(MINUTE_MICROSECOND FROM..)
-
- Closed
-
-
MDEV-12860 Out-of-range error on CREATE..SELECT with a view using MAX and EXTRACT(MINUTE_MICROSECOND..)
-
- Closed
-
-
MDEV-12861 FIRST_VALUE() does not preserve the exact data type
-
- Closed
-
-
MDEV-12862 Data type of @a:=1e0 depends on the session character set
-
- Closed
-
-
MDEV-12866 Out-of-range error with CREATE..SELECT..TO_SECONDS(NOW())
-
- Closed
-
-
MDEV-12876 Wrong data type for CREATE..SELECT sp_var
-
- Closed
-
-
MDEV-12916 Wrong column data type for an INT field of a cursor-anchored ROW variable
-
- Closed
-
-
MDEV-12917 Wrong data type for CREATE..SELECT year_sp_variable
-
- Closed
-
-
MDEV-12932 Remove enum Cast_target and use Type_handler to handle CAST
-
- Closed
-
-
MDEV-13526 Add Type_handler::Item_val_bool()
-
- Closed
-
-
MDEV-13964 Parameter data type control for Item_real_func
-
- Closed
-
-
MDEV-13965 Parameter data type control for Item_longlong_func
-
- Closed
-
-
MDEV-13966 Parameter data type control for Item_temporal_func
-
- Closed
-
-
MDEV-13967 Parameter data type control for Item_long_func
-
- Closed
-
-
MDEV-13995 MAX(timestamp) returns a wrong result near DST change
-
- Closed
-
-
MDEV-13997 Change Item_bool_rowready_func2 to cache const items at fix time rather than evaluation time
-
- Closed
-
-
MDEV-14454 Binary protocol returns wrong collation ID for SP OUT parameters
-
- Closed
-
-
MDEV-14467 Item_param: replace {INT|DECIMAL|REAL|STRING|TIME}_VALUE with Type_handler
-
- Closed
-
-
MDEV-14494 Move set_param_xxx() in sql_prepare.cc to methods in Item_param and Type_handler
-
- Closed
-
-
MDEV-14630 Replace {STRING|INT|REAL|DECIMAL|DATE}_ITEM to CONST_ITEM
-
- Closed
-
-
MDEV-15205 Remove mysql_type_to_time_type()
-
- Closed
-
-
MDEV-15293 CAST(AS TIME) returns bad results for LAST_VALUE(),NAME_CONST(),SP variable
-
- Closed
-
-
MDEV-15340 Wrong result HOUR(case_expression_with_time_and_datetime)
-
- Closed
-
-
MDEV-15363 Wrong result for CAST(LAST_DAY(TIME'00:00:00') AS TIME)
-
- Closed
-
-
MDEV-15406 NO_ZERO_IN_DATE erroneously affects how CAST(AS DATE) warns about fractional digit truncation
-
- Closed
-
-
MDEV-15597 Add class Load_data_outvar and avoid using Item::STRING_ITEM for Item_user_var_as_out_param detection
-
- Closed
-
-
MDEV-15689 Fix Item_func_set_collation to pass the collation using CHARSET_INFO instead of Item
-
- Closed
-
-
MDEV-15702 Remove the use of STRING_ITEM from Item_func_date_format::fix_length_and_dec()
-
- Closed
-
-
MDEV-15714 Remove the use of STRING_ITEM from the parser
-
- Closed
-
-
MDEV-15758 Split Item_bool_func::get_mm_leaf() into virtual methods in Field and Type_handler
-
- Closed
-
-
MDEV-15834 The code in TABLE_SHARE::init_from_binary_frm_image() is not safe
-
- Closed
-
-
MDEV-15926 MEDIUMINT returns wrong I_S attributes
-
- Closed
-
-
MDEV-15946 MEDIUMINT(N<8) creates a wrong data type on conversion to string
-
- Closed
-
-
MDEV-15957 Unexpected "Data too long" when doing CREATE..SELECT with stored functions
-
- Closed
-
-
MDEV-15960 Wrong data type on CREATE..SELECT char_or_enum_or_text_spvar
-
- Closed
-
-
MDEV-15971 Split the code for CHARACTER_OCTET_LENGTH and CHARACTER_MAXIMUM_LENGTH into methods in Field
-
- Closed
-
-
MDEV-16280 Add class Bit_addr
-
- Closed
-
-
MDEV-16309 Split ::create_tmp_field() into virtual methods in Item
-
- Closed
-
-
MDEV-16316 Replace INT_ITEM references in the code behind ORDER, LIMIT, PROCEDURE clause
-
- Closed
-
-
MDEV-16320 Replace INT_ITEM references in sql_select.cc
-
- Closed
-
-
MDEV-16351 JSON_OBJECT() treats hybrid functions with boolean arguments as numbers
-
- Closed
-
-
MDEV-16379 Move Item_basic_const::used_table_map to Item_cache
-
- Closed
-
-
MDEV-16385 ROW SP variable is allowed in unexpected context
-
- Closed
-
-
MDEV-16388 Replace member Item::fixed to virtual method is_fixed()
-
- Closed
-
-
MDEV-16414 Add type_handler_xpath_nodeset and remove XPATH_NODESET
-
- Closed
-
-
MDEV-16426 Optimizer erroneously treats equal constants of different formats as same
-
- Closed
-
-
MDEV-16451 Split Item_equal::add_const() into a virtual method in type_handler()
-
- Closed
-
-
MDEV-16452 Split TIME and DATETIME handling in Item_func_between, in_temporal, cmp_item_internal
-
- Closed
-
-
MDEV-16454 Bad results for IN with ROW
-
- Closed
-
-
MDEV-16806 Add Type_handler::create_literal_item()
-
- Closed
-
-
MDEV-16814 CREATE TABLE SELECT JSON_QUOTE(multibyte_charset_expr) makes a field of a wrong length
-
- Closed
-
-
MDEV-16823 Add Type_handler::Column_definition_reuse_fix_attributes()
-
- Closed
-
-
MDEV-16852 Get rid of Item_temporal_hybrid_func::fix_temporal_type()
-
- Closed
-
-
MDEV-16861 Split Item::update_null_value() into a new virtual method in Type_handler
-
- Closed
-
-
MDEV-16864 Implement class Item_func_timestamp
-
- Closed
-
-
MDEV-16874 Implement class Item_handled_func
-
- Closed
-
-
MDEV-16881 Remove Item::get_temporal_with_sql_mode() and val_xxx_from_date()
-
- Closed
-
-
MDEV-16884 Remove tests for field_type() in Item_cache_temporal
-
- Closed
-
-
MDEV-16888 Add virtual Type_handler::cond_notnull_field_isnull_to_field_eq_zero()
-
- Closed
-
-
MDEV-16926 CAST(COALESCE(year_field)) returns wrong value
-
- Closed
-
-
MDEV-16939 Move TIMESTAMP truncation code to Field_timestamp::store_TIME_with_warn
-
- Closed
-
-
MDEV-17325 NULL-ability problems with LEAST() in combination with NO_ZERO_DATE and NO_ZERO_IN_DATE
-
- Closed
-
-
MDEV-17330 Wrong result for 0 + LEAST(TIME'-10:00:00',TIME'10:00:00')
-
- Closed
-
-
MDEV-17625 Different warnings when comparing a garbage to DATETIME vs TIME
-
- Closed
-
-
MDEV-17905 Add class Charset
-
- Closed
-
-
MDEV-19125 Change Send_field::type from enum_field_types to Type_handler*
-
- Closed
-
-
MDEV-19197 Move ASSERT_COLUMN_MARKED_FOR_XXX as methods to Field
-
- Closed
-
-
MDEV-19317 TEXT column accepts too long literals as a default value
-
- Closed
-
-
MDEV-19345 Cleanup inconsistency in setting HA_(BLOB|VAR_LENGTH|BIT)_PART flags
-
- Closed
-
-
MDEV-19377 Replace Virtual_column_info::field_type to Type_handler
-
- Closed
-
-
MDEV-19550 Move specific parts of log_event.cc to log_event_client.cc and log_event_server.cc
-
- Closed
-
-
MDEV-19566 Remove Item::name related strlen() calls in constructors of some Item_string descendands
-
- Closed
-
-
MDEV-19593 Split create_schema_table() into virtual methods in Type_handler
-
- Closed
-
-
MDEV-19612 Split ALTER related data type specific code in sql_table.cc to Type_handler
-
- Closed
-
-
MDEV-19686 Add method Type_handler::dyncol_type
-
- Closed
-
-
MDEV-19710 Split the server side code in rpl_utility.cc into virtual methods in Type_handler
-
- Closed
-
-
MDEV-19724 Add Field::tmp_engine_column_type()
-
- Closed
-
-
MDEV-19727 Add Type_handler::Key_part_spec_init_ft
-
- Closed
-
-
MDEV-19772 Add helper classes for ST_FIELD_INFO
-
- Closed
-
-
MDEV-19810 Reuse new I_S table definition helper classes for InnoDB
-
- Closed
-
-
MDEV-19818 Reuse new I_S table definition helper classes for TokuDB
-
- Closed
-
-
MDEV-19843 Modify ST_FIELD_INFO to use Type_handler and LEX_CSTRING
-
- Closed
-
-
MDEV-19888 Add abstract class Item_json_func
-
- Closed
-
-
MDEV-19908 Add class Type_collection
-
- Closed
-
-
MDEV-19923 Add type handlers for geometry sub-types
-
- Closed
-
-
MDEV-19944 Remove GIS data types from keyword list in lex.h
-
- Closed
-
-
MDEV-19957 Move Type_handler_geometry code from sql_type.h/cc to sql_type_geom.h/cc
-
- Closed
-
-
MDEV-19972 Move GIS code from Item_bool_func::get_full_func_mm_tree() to Item_func_spatial_rel::get_mm_leaf()
-
- Closed
-
-
MDEV-19991 Turn I_S tables GEOMETRY_COLUMNS and SPATIAL_REF_SYS into a plugin
-
- Closed
-
-
MDEV-19994 Add class Function_collection
-
- Closed
-
-
MDEV-20006 Move geometry specific code in Field_blob::get_key_image() to Field_geom
-
- Closed
-
-
MDEV-20009 Add CAST(expr AS pluggable_type)
-
- Closed
-
-
MDEV-20016 Add MariaDB_DATA_TYPE_PLUGIN
-
- Closed
-
-
MDEV-20042 Implement EXTRA2_FIELD_DATA_TYPE_INFO in FRM
-
- Closed
-
-
MDEV-20052 Add a MEM_ROOT pointer argument to Type_handler::make_xxx_field()
-
- Closed
-
-
MDEV-20175 Move Type_handler_row from Type_collection_std to Type_collection_row
-
- Closed
-
-
MDEV-20326 Add class DTCollation_numeric
-
- Closed
-
-
MDEV-20332 Wrong UNSIGNED metadata flag returned for COALESCE(unsigned_field,timestamp_field)
-
- Closed
-
-
MDEV-20342 Turn Field::flags from a member to a method
-
- Closed
-
-
MDEV-20351 Window function BIT_OR() OVER (..) return a wrong data type
-
- Closed
-
-
MDEV-20353 Add separate type handlers for unsigned integer data types
-
- Closed
-
-
MDEV-20674 Reuse val_native() in ExtractValue() and UpdateXML()
-
- Closed
-
-
MDEV-20696 Remove Column_definition::key_length
-
- Closed
-
-
MDEV-20704 An index on a double column erroneously uses prefix compression
-
- Closed
-
-
MDEV-20706 Store scale in Column_definition::decimals rather than Column_definition::pack_flag
-
- Closed
-
-
MDEV-20708 Change make_table_field() to get TABLE_SHARE rather than TABLE
-
- Closed
-
-
MDEV-20712 Wrong data type for CAST(@a AS BINARY) for a numeric variable
-
- Closed
-
-
MDEV-20716 Unify make_table_field() and make_table_field_from_def() for integer and real types
-
- Closed
-
-
MDEV-20721 Implement sql_type() for Field_real and Field_int
-
- Closed
-
-
MDEV-20734 Allow reserved keywords as user defined type names
-
- Closed
-
-
MDEV-20760 Add Type_handler::KEY_pack_flags()
-
- Closed
-
-
MDEV-20764 Add MariaDB_FUNCTION_COLLECTION_PLUGIN
-
- Closed
-
-
MDEV-20831 Table partitioned by LIST/RANGE COLUMNS(inet6) can be created, but not inserted into
-
- Closed
-
-
MDEV-20837 Add MariaDB_FUNCTION_PLUGIN
-
- Closed
-
- relates to
-
MDEV-16443 JSON can not be implemented as a alias for longtext
-
- Closed
-
-
MDEV-20016 Add MariaDB_DATA_TYPE_PLUGIN
-
- Closed
-
-
MDEV-21389 Derive Item_func_month from Item_long_func
-
- Closed
-
-
MDEV-4405 Dynamic Columns compression
-
- Open
-
-
MDEV-4631 CassandraSE: Encrypted column data type
-
- Closed
-
-
MDEV-5593 Feature request native support for UUID's as a column type
-
- Closed
-
-
MDEV-8284 Comparison of YEAR to '1970' is not consistent
-
- Open
-
-
MDEV-9417 "CREATE TABLE t1 SELECT int_sp_argument" produces a too large column
-
- Open
-
-
MDEV-9425 Hybrid functions and UNION do not preserve spatial REF_SYSTEM_ID
-
- Confirmed
-
-
MDEV-11361 Equal condition propagation does not work for DECIMAL and temporal dynamic SQL parameters
-
- Open
-
-
MDEV-11362 True condition elimination does not work for DECIMAL and temporal dynamic SQL parameters
-
- Closed
-
-
MDEV-15924 Wrong field type for CAST(temporal_column AS [UN]SIGNED)
-
- Open
-
-
MDEV-19927 Non-spatial key on POINT silently changes prefix key length
-
- Confirmed
-
-
MDEV-21392 Cleanup redundant overriding in Item_sum_num
-
- Closed
-
-
MDEV-23290 Add overloading support in MariaDB_FUNCTION_PLUGIN
-
- Open
-
- links to
Activity
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" |
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" |
Remote Link | This issue links to "PostgreSQL field type (Web Link)" [ 12105 ] |
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... |
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... |
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... |
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... |
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 |
Fix Version/s | 10.1.0 [ 12200 ] |
Labels | gsoc14 |
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 |
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_ |
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_ |
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_ |
Assignee | Alexander Barkov [ bar ] |
Fix Version/s | 10.1.1 [ 16100 ] | |
Fix Version/s | 10.1.0 [ 12200 ] |
Workflow | defaullt [ 28427 ] | MariaDB v2 [ 43674 ] |
Priority | Major [ 3 ] | Minor [ 4 ] |
Status | Open [ 1 ] | In Progress [ 3 ] |
Workflow | MariaDB v2 [ 43674 ] | MariaDB v3 [ 67312 ] |
Fix Version/s | 10.2 [ 14601 ] | |
Fix Version/s | 10.1 [ 16100 ] |
Labels | gsoc14 |
Labels | gsoc14 |
Sprint | 10.2.0-1 [ 21 ] |
Rank | Ranked lower |
Sprint | 10.2.0-1 [ 21 ] | 10.2.0-1, 5.5.47-1 [ 21, 22 ] |
Rank | Ranked higher |
Sprint | 10.2.0-1, 5.5.47-1 [ 21, 22 ] | 10.2.0-1 [ 21 ] |
Rank | Ranked lower |
Sprint | 10.2.0-1 [ 21 ] | 10.2.0-1, 10.2.0-2 [ 21, 26 ] |
Rank | Ranked lower |
Rank | Ranked higher |
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 ] |
Rank | Ranked higher |
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 ] |
Rank | Ranked lower |
Labels | gsoc14 | gsoc14 gsoc16 |
Labels | gsoc14 gsoc16 | gsoc14 |
Assignee | Alexander Barkov [ bar ] | Sergei Golubchik [ serg ] |
Status | In Progress [ 3 ] | In Review [ 10002 ] |
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 ] |
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 ] |
Rank | Ranked lower |
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 ] |
Rank | Ranked lower |
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 ] |
Rank | Ranked higher |
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 ] |
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 ] |
Rank | Ranked higher |
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 ] |
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 ] |
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 ] |
Rank | Ranked lower |
Fix Version/s | 10.2 [ 14601 ] |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link | This issue is blocked by MDEV-11304 [ MDEV-11304 ] |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link | This issue is blocked by MDEV-11458 [ MDEV-11458 ] |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link | This issue is blocked by MDEV-11511 [ MDEV-11511 ] |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Assignee | Sergei Golubchik [ serg ] | Alexander Barkov [ bar ] |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link | This issue blocks MDEV-10593 [ MDEV-10593 ] |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Status | In Review [ 10002 ] | Stalled [ 10000 ] |
Status | Stalled [ 10000 ] | In Progress [ 3 ] |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link | This issue is blocked by MDEV-12503 [ MDEV-12503 ] |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link | This issue is blocked by MDEV-10902 [ MDEV-10902 ] |
Link | This issue is blocked by MDEV-12513 [ MDEV-12513 ] |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link | This issue is blocked by MDEV-12565 [ MDEV-12565 ] |
Link | This issue is blocked by MDEV-12566 [ MDEV-12566 ] |
Link | This issue is blocked by MDEV-12567 [ MDEV-12567 ] |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link | This issue is blocked by MDEV-12613 [ MDEV-12613 ] |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link | This issue is blocked by MDEV-12712 [ MDEV-12712 ] |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link | This issue is duplicated by MDEV-12786 [ MDEV-12786 ] |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link | This issue is blocked by MDEV-12828 [ MDEV-12828 ] |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link | This issue blocks MDEV-12786 [ MDEV-12786 ] |
Link | This issue is duplicated by MDEV-12786 [ MDEV-12786 ] |
Link | This issue blocks MDEV-11058 [ MDEV-11058 ] |
Link |
This issue blocks |
Link | This issue blocks MDEV-10592 [ MDEV-10592 ] |
Link | This issue blocks MDEV-10575 [ MDEV-10575 ] |
Link | This issue blocks MDEV-12307 [ MDEV-12307 ] |
Link | This issue blocks MDEV-12308 [ MDEV-12308 ] |
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 ] |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link | This issue is blocked by MDEV-12927 [ MDEV-12927 ] |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link | This issue relates to MDEV-11361 [ MDEV-11361 ] |
Link |
This issue relates to |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link | This issue is blocked by MDEV-14661 [ MDEV-14661 ] |
Link | This issue is blocked by MDEV-14910 [ MDEV-14910 ] |
Link |
This issue is blocked by |
Link |
This issue blocks |
Link |
This issue blocks |
Link |
This issue is blocked by |
Link | This issue is blocked by MDEV-15310 [ MDEV-15310 ] |
Link |
This issue is blocked by |
Link |
This issue blocks |
Link |
This issue blocks |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link | This issue is blocked by MDEV-15704 [ MDEV-15704 ] |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link | This issue is blocked by MDEV-15927 [ MDEV-15927 ] |
Link | This issue relates to MDEV-15924 [ MDEV-15924 ] |
Link | This issue is blocked by MDEV-15901 [ MDEV-15901 ] |
Link | This issue is blocked by MDEV-15930 [ MDEV-15930 ] |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue relates to |
Link |
This issue relates to |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link | This issue is blocked by MDEV-16324 [ MDEV-16324 ] |
Link | This issue is blocked by MDEV-16325 [ MDEV-16325 ] |
Link |
This issue is blocked by |
Link | This issue is blocked by MDEV-16373 [ MDEV-16373 ] |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link | This issue blocks MDEV-11829 [ MDEV-11829 ] |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link | This issue blocks MDEV-10018 [ MDEV-10018 ] |
Link | This issue is blocked by MDEV-12513 [ MDEV-12513 ] |
Link | This issue blocks MDEV-12513 [ MDEV-12513 ] |
Link |
This issue is blocked by |
Link | This issue is blocked by MDEV-17329 [ MDEV-17329 ] |
Link |
This issue is blocked by |
Link | This issue is blocked by MDEV-17335 [ MDEV-17335 ] |
Link | This issue is blocked by MDEV-17384 [ MDEV-17384 ] |
Link |
This issue relates to |
Link |
This issue is blocked by |
Link | This issue is blocked by MDEV-17632 [ MDEV-17632 ] |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link | This issue is blocked by MDEV-19180 [ MDEV-19180 ] |
Link | This issue is blocked by MDEV-19196 [ MDEV-19196 ] |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link | This issue is blocked by MDEV-19708 [ MDEV-19708 ] |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link | This issue relates to MDEV-19927 [ MDEV-19927 ] |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Issue Type | Task [ 3 ] | Epic [ 5 ] |
Link |
This issue is blocked by |
Fix Version/s | 10.5 [ 23123 ] |
Link | This issue is blocked by MDEV-20343 [ MDEV-20343 ] |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link | This issue blocks MENT-412 [ MENT-412 ] |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Epic Name | Add a plugin to field types (column types) |
Summary | Add a plugin to field types (column types) | Data type plugin API version 1 |
Link | This issue is blocked by MDEV-10902 [ MDEV-10902 ] |
Link | This issue is blocked by MDEV-11304 [ MDEV-11304 ] |
Link | This issue is blocked by MDEV-11458 [ MDEV-11458 ] |
Link | This issue is blocked by MDEV-11511 [ MDEV-11511 ] |
Link |
This issue is blocked by |
Link | This issue is blocked by MDEV-12503 [ MDEV-12503 ] |
Link | This issue is blocked by MDEV-12613 [ MDEV-12613 ] |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link | This issue is blocked by MDEV-12712 [ MDEV-12712 ] |
Link | This issue is blocked by MDEV-12828 [ MDEV-12828 ] |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link | This issue is blocked by MDEV-14661 [ MDEV-14661 ] |
Link | This issue is blocked by MDEV-14910 [ MDEV-14910 ] |
Link | This issue is blocked by MDEV-15310 [ MDEV-15310 ] |
Link | This issue is blocked by MDEV-15704 [ MDEV-15704 ] |
Link | This issue is blocked by MDEV-15901 [ MDEV-15901 ] |
Link | This issue is blocked by MDEV-15927 [ MDEV-15927 ] |
Link | This issue is blocked by MDEV-15930 [ MDEV-15930 ] |
Link | This issue is blocked by MDEV-16324 [ MDEV-16324 ] |
Link | This issue is blocked by MDEV-16325 [ MDEV-16325 ] |
Link | This issue is blocked by MDEV-19708 [ MDEV-19708 ] |
Link |
This issue is blocked by |
Link | This issue is blocked by MDEV-19180 [ MDEV-19180 ] |
Link | This issue is blocked by MDEV-17632 [ MDEV-17632 ] |
Link | This issue is blocked by MDEV-17335 [ MDEV-17335 ] |
Link | This issue is blocked by MDEV-20343 [ MDEV-20343 ] |
Link |
This issue is blocked by |
Link | This issue is blocked by MDEV-19196 [ MDEV-19196 ] |
Link | This issue is blocked by MDEV-17384 [ MDEV-17384 ] |
Link | This issue is blocked by MDEV-17329 [ MDEV-17329 ] |
Link | This issue is blocked by MDEV-16373 [ MDEV-16373 ] |
Link | This issue is blocked by MDEV-12927 [ MDEV-12927 ] |
Link |
This issue relates to |
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 ] |
Link |
This issue relates to |
Link |
This issue relates to |
Link | This issue relates to MDEV-23290 [ MDEV-23290 ] |
Workflow | MariaDB v3 [ 67312 ] | MariaDB v4 [ 146953 ] |
Priority | Minor [ 4 ] | Major [ 3 ] |
Priority | Minor [ 4 ] | Major [ 3 ] |
Comment | [ A comment with security level 'Developers' was removed. ] |
Comment | [ A comment with security level 'Developers' was removed. ] |
Priority | Major [ 3 ] | Minor [ 4 ] |
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...