maria-developers team mailing list archive

[Oleksandr Byelkin <sanja@xxxxxxxxxxxx>]

Michael Widenius wrote:
> Hi!
>
>   
>>>>>> "Oleksandr" == Oleksandr Byelkin <sanja@xxxxxxxxxxxx> writes:
>>>>>>             
>
> Oleksandr> Michael Widenius wrote:
> Oleksandr> [skip]
>   
>>>> +  DBUG_ENTER("create_table_list_merge");
>>>> +
>>>> +  for(; changes; changes= changes->next)
>>>> +  {
>>>> +    if (create_option_add(&source, root, &changes->key, &changes->val,
>>>> +                          (chng ? NULL : &chng)))
>>>>
>>>>         
>>> Instead of test, send &chng to function and do:
>>> (*changed)|= chng;
>>>
>>>       
> Oleksandr> It will make create_option_add more complicated, because it need info
> Oleksandr> was that change in this list.
>
> Sorry, but don't understand the above.
>
> I didn't notice before that the create_option_add() function does things
> differently if changed is set or not.
>
> I looked at the function create_option_list() but don't understand why
> you copy all other arguments after you have found the first change,
> even if the value didn't change.
>
> The function prototype of create_option_add() also doesn't tell
> anything about this strange usage of 'changed'.
>
> So the question is:  Why does create_option_add() work differently if
> changed is set or not?
>   
There was undocumented behavior (my fault).

If changed or not is not interesting for us it was called from parser
and will leave only untill we write it to frm.
Otherwise it was called from ALTER table and if we will not copy it
memroot where it was created will be freed earlier that we need (it was
hard-to-find-bug).

[skip]
>>>> === modified file 'sql/table.h'
>>>> --- sql/table.h	2009-11-12 04:31:28 +0000
>>>> +++ sql/table.h	2009-12-01 20:45:54 +0000
>>>> @@ -310,6 +310,7 @@
>>>> #ifdef NOT_YET
>>>> struct st_table *open_tables;		/* link to open tables */
>>>> #endif
>>>> +  TABLE_OPTIONS *create_table_options;  /* text options for table */
>>>>
>>>>
>>>>         
>>> See comment that we should consider making this a full object, not a pointer
>>>
>>>       
> Oleksandr> We have plugins on C and I think it will be inconvenient to convert
> Oleksandr> object to something C can read.
>
> There is no difference for C if the above variable is a TABLE_OPTIONS
> or TABLE_OPTIONS *;  We can always send the pointer to the struct
> for any function that would need it.
>   
Sorry I misunderstood you. then OK I'll try to fix it.