From 441b53f8ba15c20428035e076a7ea895b37b128d Mon Sep 17 00:00:00 2001 From: Mikael Ronstrom Date: Thu, 29 Oct 2009 18:04:23 +0100 Subject: Changed COLUMN_LIST to COLUMNS after arch review --- sql/lex.h | 1 - sql/opt_range.cc | 2 +- sql/sql_partition.cc | 6 +++--- sql/sql_yacc.yy | 3 +-- 4 files changed, 5 insertions(+), 7 deletions(-) (limited to 'sql') diff --git a/sql/lex.h b/sql/lex.h index 1a119d2a30b..cd0c042159f 100644 --- a/sql/lex.h +++ b/sql/lex.h @@ -119,7 +119,6 @@ static SYMBOL symbols[] = { { "COLUMN", SYM(COLUMN_SYM)}, { "COLUMN_NAME", SYM(COLUMN_NAME_SYM)}, { "COLUMNS", SYM(COLUMNS)}, - { "COLUMN_LIST", SYM(COLUMN_LIST_SYM)}, { "COMMENT", SYM(COMMENT_SYM)}, { "COMMIT", SYM(COMMIT_SYM)}, { "COMMITTED", SYM(COMMITTED_SYM)}, diff --git a/sql/opt_range.cc b/sql/opt_range.cc index fb342359c5f..ce86fa535fe 100644 --- a/sql/opt_range.cc +++ b/sql/opt_range.cc @@ -3251,7 +3251,7 @@ int find_used_partitions(PART_PRUNE_PARAM *ppar, SEL_ARG *key_tree) /* We need to call the interval mapper if we have a condition which - makes sense to prune on. In the example of a COLUMN_LIST on a and + makes sense to prune on. In the example of COLUMNS on a and b it makes sense if we have a condition on a, or conditions on both a and b. If we only have conditions on b it might make sense but this is a harder case we will solve later. For the harder case diff --git a/sql/sql_partition.cc b/sql/sql_partition.cc index ec16ff29eaa..ba99d8b45b4 100644 --- a/sql/sql_partition.cc +++ b/sql/sql_partition.cc @@ -68,7 +68,7 @@ const LEX_STRING partition_keywords[]= { C_STRING_WITH_LEN("KEY") }, { C_STRING_WITH_LEN("MAXVALUE") }, { C_STRING_WITH_LEN("LINEAR ") }, - { C_STRING_WITH_LEN(" COLUMN_LIST") } + { C_STRING_WITH_LEN(" COLUMNS") } }; static const char *part_str= "PARTITION"; static const char *subpart_str= "SUBPARTITION"; @@ -6925,7 +6925,7 @@ void make_used_partitions_str(partition_info *part_info, String *parts_str) (1) is applicable for "PARTITION BY (func(t.field))", where func is a monotonic function. - (2) is applicable for "PARTITION BY COLUMN_LIST (field_list) + (2) is applicable for "PARTITION BY COLUMNS (field_list) (3) is applicable for "[SUB]PARTITION BY (any_func(t.integer_field))" @@ -7624,7 +7624,7 @@ uint32 get_next_partition_id_range(PARTITION_ITERATOR* part_iter) DESCRIPTION This implementation of PARTITION_ITERATOR::get_next() is special for LIST partitioning: it enumerates partition ids in - part_info->list_array[i] (list_col_array[i] for COLUMN_LIST LIST + part_info->list_array[i] (list_col_array[i] for COLUMNS LIST partitioning) where i runs over [min_idx, max_idx] interval. The function conforms to partition_iter_func type. diff --git a/sql/sql_yacc.yy b/sql/sql_yacc.yy index a8813fedd27..b6e3bfa4fb5 100644 --- a/sql/sql_yacc.yy +++ b/sql/sql_yacc.yy @@ -611,7 +611,6 @@ bool my_yyoverflow(short **a, YYSTYPE **b, ulong *yystacksize); %token COLLATE_SYM /* SQL-2003-R */ %token COLLATION_SYM /* SQL-2003-N */ %token COLUMNS -%token COLUMN_LIST_SYM %token COLUMN_SYM /* SQL-2003-R */ %token COLUMN_NAME_SYM /* SQL-2003-N */ %token COMMENT_SYM @@ -4121,7 +4120,7 @@ part_field_item: ; part_column_list: - COLUMN_LIST_SYM '(' part_field_list ')' + COLUMNS '(' part_field_list ')' { partition_info *part_info= Lex->part_info; part_info->column_list= TRUE; -- cgit v1.2.1