Hi!
The goals of the system as I can see:
- Fast reading frm (time taken by plugin processing of the data should be
counted too).
- Should be easy usable for plugins with simple requirements and allow plugins
process some special types if they wants.
Syntax parsing give as pair (key,value) where value will be string. Many
parameters will need numbers (for numbers, enums or sets) and converting
string->number every time we need the value IMHO is wasting of CPU time. So
in frm it is better to store number.
Syntax check and fitting parameters value in allowed range will be done by
plugin in any case, so IMHO better then write this function for every plugin
make standard my_opt like function for this which can be usable by most
plugins.
To allow plugins implement some rare and complex constructions a plugin
can provide function for parsing and checking unrecognised pairs (if function
is absent then such pair is error).
According to above I propose following construction:
enum enum_plugin_parameter_type {
HA_PLUGIN_PARAMETER_STRING,
HA_PLUGIN_PARAMETER_NUM,
HA_PLUGIN_PARAMETER_ENUM,
HA_PLUGIN_PARAMETER_SET
};
struct st_plugin_parameter {
struct st_plugin_parameter *next;
LEX_STRING key;
LEX_STRING value;
enum enum_plugin_parameter_type type;
}
The list do not contain field/key/table reference because it will be attached
to field/key/list definition.
After parsing they all will have string values then will be called function
with this list, array of description of parameters provided by plugin and
plugin callback.
The function convert type of parameter (if it is needed) and check parameter
value (can be switchable). For numbers and enums after parsing type will be
changed and value will contain binary data.
In the frm data will be stored according to its type (to avoid string ->
number conversion after frm read). reading frm parameters will generate the
same list (on which plugin can apply check function in debugging purposes or
to process very specific for this plugin complex constructions which was
saved in strings.
In the frm we will store length of whole block of parameters and its number
(4/2 bytes). For for every option we will store:
1 byte: Belong to table/field/value
2 bytes: (if needed): key/field number
1 byte: Type (string/num/enum/set) (can be combined with first byte)
1 byte: key length
2 bytes: data length
<key value>
<data>
The only problem I see is how to pass some unified information about
table/field/key to handler callback for processing unrecognized by simple
parser parameters (need for advanced parameters check). Because Parser and
frm reader collect information about table/field/key in different structures
(actually for parser it is C++ object which add problems for interface)
Simple parameter parser will work with array of descriptors (like my_opts)
where name/type/max/min values will be listed. Plugin provide 3 arrays:
table/field/key.
