Hi!
This if fix of plan after discussing with Monty.
В сообщении от Thursday 29 May 2008 17:35:29 Oleksandr "Sanja" Byelkin
написал(а):
> 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.
There was found yet another requirement:
- data should be saved if the table is altered to other engine or in
replication for master and slave used different engines.
Syntax parsing give as pair (key,value) where value will be string and it will
be stored in frm. Many parameters will need numbers (for numbers, enums or
sets) and mysql will provide my_opt-like function which will help engine to
parse the parameters and send warnings to client if can't recognize
parameter. If engine wants something else or more complex it can use callback
of the function or has its own parsing procedure.
[skip]
> According to above I propose following construction:
[skip]
> struct st_plugin_parameter {
> struct st_plugin_parameter *next;
> LEX_STRING key;
> LEX_STRING value;
[skip]
> }
>
> The list do not contain field/key/table reference because it will be
> attached to field/key/list definition.
The parser will set values of engine variables by referrence (including
default value) like my_opts.
> 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
[skip]
> 1 byte: key length
> 2 bytes: data length
> <key value>
> <data>
[skip]

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.