maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Hi Bar,

Can you please merge the following patch 10.0 -> 10.1?

    commit bc902a2bfc46add0708896c07621e3707f66d95f
    Author: Alexander Barkov <bar@xxxxxxxxxxx>
    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