maria-developers team mailing list archive

[Michael Widenius <monty@xxxxxxxxxxxx>]

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?

Oleksandr> [skip]
>>> */
>>> if (tablespace &&
>>> (table->file->get_tablespace_name(thd, tablespace, FN_LEN)))
>>> @@ -6089,6 +6102,30 @@
>>> }
>>> restore_record(table, s->default_values);     // Empty record for DEFAULT
>>> 
>>> +  if (create_info->create_table_options_orig.table_opt)
>>> +  {
>>> +    my_bool changed= FALSE;
>>> +    create_info->create_table_options_orig.table_opt=
>>> 
>> 
>> Can't we ensure that table->s->create_table_options always exists?
>> It would remove a lot of if's in your code.

Oleksandr> It is difficult because temporary tables involved.

As temporary tables is only created in one place it would be trivial
to ensure that the pointer always exits.

Oleksandr> [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.

Regards,
Monty