Hi Bar,
Can you please merge the following patch 10.0 -> 10.1?
commit bc902a2bfc46add0708896c07621e3707f66d95f
Author: Alexander Barkov
Date: Fri Mar 13 16:12:54 2015 +0400
MDEV-7387 [PATCH] Alter table xxx CHARACTER SET utf8, CONVERT TO CHARACTER SET latin1 should fail
Eg. run `git merge bc902a2bfc46add0708896c07621e3707f66d95f` in a 10.1 tree.
Or alternatively, tell me how to resolve the below conflict in the merge,
which is seen in sql/handler.h, so I can do the merge?
(This conflict is blocking me from pushing MDEV-7249, MDEV-5289, MDEV-7668,
and MDEV-7802 into 10.1...)
- Kristian.
-----------------------------------------------------------------------
sql/handler.h:
<<<<<<< HEAD
void init()
{
bzero(this, sizeof(*this));
}
bool tmp_table() const { return options & HA_LEX_CREATE_TMP_TABLE; }
void use_default_db_type(THD *thd)
{
db_type= tmp_table() ? ha_default_tmp_handlerton(thd)
: ha_default_handlerton(thd);
}
};
/**
This struct is passed to handler table routines, e.g. ha_create().
It does not include the "OR REPLACE" and "IF NOT EXISTS" parts, as these
parts are handled on the SQL level and are not needed on the handler level.
*/
struct HA_CREATE_INFO: public Table_scope_and_contents_source_st,
public Schema_specification_st
{
void init()
{
Table_scope_and_contents_source_st::init();
Schema_specification_st::init();
}
};
/**
This struct is passed to mysql_create_table() and similar creation functions,
as well as to show_create_table().
*/
struct Table_specification_st: public HA_CREATE_INFO,
public DDL_options_st
{
// Deep initialization
void init()
{
HA_CREATE_INFO::init();
DDL_options_st::init();
}
void init(DDL_options_st::Options options)
{
HA_CREATE_INFO::init();
DDL_options_st::init(options);
}
/*
Quick initialization, for parser.
Most of the HA_CREATE_INFO is left uninitialized.
It gets fully initialized in sql_yacc.yy, only when the parser
scans a related keyword (e.g. CREATE, ALTER).
*/
void lex_start()
{
HA_CREATE_INFO::options= 0;
DDL_options_st::init();
}
||||||| merged common ancestors
bool tmp_table() { return options & HA_LEX_CREATE_TMP_TABLE; }
=======
bool tmp_table() { return options & HA_LEX_CREATE_TMP_TABLE; }
bool check_conflicting_charset_declarations(CHARSET_INFO *cs);
bool add_table_option_default_charset(CHARSET_INFO *cs)
{
// cs can be NULL, e.g.: CREATE TABLE t1 (..) CHARACTER SET DEFAULT;
if (check_conflicting_charset_declarations(cs))
return true;
default_table_charset= cs;
used_fields|= HA_CREATE_USED_DEFAULT_CHARSET;
return false;
}
bool add_alter_list_item_convert_to_charset(CHARSET_INFO *cs)
{
/*
cs cannot be NULL, as sql_yacc.yy translates
CONVERT TO CHARACTER SET DEFAULT
to
CONVERT TO CHARACTER SET <character-set-of-the-current-database>
TODO: Should't we postpone resolution of DEFAULT until the
character set of the table owner database is loaded from its db.opt?
*/
DBUG_ASSERT(cs);
if (check_conflicting_charset_declarations(cs))
return true;
table_charset= default_table_charset= cs;
used_fields|= (HA_CREATE_USED_CHARSET | HA_CREATE_USED_DEFAULT_CHARSET);
return false;
}
> bc902a2bfc46add0708896c07621e3707f66d95f
