List:Maria Storage Engine« Previous MessageNext Message »
From:Oleksandr \"Sanja\" Byelkin Date:June 2 2008 1:43pm
Subject:Re: Plan of making engine parameters for frm (WL#2938)
View as plain text  

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.


> According to above I propose following construction:
> struct st_plugin_parameter {
>   struct st_plugin_parameter *next;
>   LEX_STRING key;
>   LEX_STRING value;
> }
> 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
> 1 byte: key length
> 2 bytes: data length
> <key value>
> <data>
Plan of making engine parameters for frm (WL#2938)Oleksandr \"Sanja\" Byelkin29 May
  • Re: Plan of making engine parameters for frm (WL#2938)Oleksandr \"Sanja\" Byelkin2 Jun