Hi!
"Oleksandr" == Oleksandr Byelkin <sanja@askmonty.org> 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