summaryrefslogtreecommitdiff
path: root/sql/lex.h
diff options
context:
space:
mode:
authorSachin Setiya <sachinsetia1001@gmail.com>2017-12-02 07:00:04 +0530
committerSachin Setiya <sachin.setiya@mariadb.com>2017-12-15 02:41:52 +0530
commit84726906c947e3021a9fd7628493bfe775e2f26f (patch)
tree6701948df86e7c45f113bbec933bf61758309f22 /sql/lex.h
parent866ccc8890a3932e260e43fa5fc7ab8170e6cc3d (diff)
downloadmariadb-git-84726906c947e3021a9fd7628493bfe775e2f26f.tar.gz
MDEV-10177 Invisible Columns and Invisible Index
Feature Definition:- This feature adds invisible column functionality to server. There is 4 level of "invisibility": 1. Not invisible (NOT_INVISIBLE) — Normal columns created by the user 2. A little bit invisible (USER_DEFINED_INVISIBLE) — columns that the user has marked invisible. They aren't shown in SELECT * and they don't require values in INSERT table VALUE (...). Otherwise they behave as normal columns. 3. More invisible (SYSTEM_INVISIBLE) — Can be queried explicitly, otherwise invisible from everything. Think ROWID sytem column. Because they're invisible from ALTER TABLE and from CREATE TABLE they cannot be created or dropped, they're created by the system. User cant not create a column name which is same as of SYSTEM_INVISIBLE. 4. Very invisible (COMPLETELY_INVISIBLE) — as above, but cannot be queried either. They can only show up in EXPLAIN EXTENDED (might be possible for a very invisible indexed virtual column) but otherwise they don't exist for the user.If user creates a columns which has same name as of COMPLETELY_INVISIBLE then COMPLETELY_INVISIBLE column is renamed again. So it is completely invisible from user. Invisible Index(HA_INVISIBLE_KEY):- Creation of invisible columns require a new type of index which will be only visible to system. User cant see/alter/create/delete this index. If user creates a index which is same name as of invisible index then it will be renamed. Syntax Details:- Only USER_DEFINED_INVISIBLE column can be created by user. This can be created by adding INVISIBLE suffix after column definition. Create table t1( a int invisible, b int); Rules:- There are some rules/restrictions related to use of invisible columns 1. All the columns in table cant be invisible. Create table t1(a int invisible); \\error Create table t1(a int invisible, b int invisble); \\error 2. If you want invisible column to be NOT NULL then you have to supply Default value for the column. Create table t1(a int, b int not null); \\error 3. If you create a view/create table with select * then this wont copy invisible fields. So newly created view/table wont have any invisible columns. Create table t2 as select * from t1;//t2 wont have t1 invisible column Create view v1 as select * from t1;//v1 wont have t1 invisible column 4. Invisibility wont be forwarded to next table in any case of create table/view as select */(a,b,c) from table. Create table t2 as select a,b,c from t1; // t2 will have t1 invisible // column(b), but this wont be invisible in t2 Create view v1 as select a,b,c from t1; // v1 will have t1 invisible // column(b), but this wont be invisible in v1 Implementation Details:- Parsing:- INVISIBLE_SYM is added into vcol_attribute(so its like unique suffix), It is also added into keyword_sp_not_data_type so that table can have column with name invisible. Implementation detail is given by each modified function/created function. (Some function are left as they were self explanatory) (m= Modified, n= Newly Created) mysql_prepare_create_table(m):- Extra checks for invisible columns are added. Also some DEBUG_EXECUTE_IF are also added for test cases. mysql_prepare_alter_table(m):- Now this will drop all the COMPLETELY_INVISIBLE column and HA_INVISIBLE_KEY index. Further Modifications are made to stop drop/change/delete of SYSTEM_INVISIBLE column. build_frm_image(m):- Now this allows incorporating field_visibility status into frm image. To remain compatible with old frms field_visibility info will be only written when any of the field is not NOT_INVISIBLE. extra2_write_additional_field_properties(n):- This will write field visibility info into buffer. We first write EXTRA2_FIELD_FLAGS into buffer/frm , then each next char will have field_visibility for each field. init_from_binary_frm_image(m):- Now if we get EXTRA2_FIELD_FLAGS, then we will read the next n(n= number of fields) chars and set the field_visibility. We also increment thd->status_var.feature_invisible_columns. One important thing to note if we find out that key contains a field whose visibility is > USER_DEFINED_INVISIBLE then , we declare this key as invisible key. sql_show.cc is changed accordingly to make show table, show keys correct. mysql_insert(m):- If we get to know that we are doing insert in this way insert into t1 values(1,1); without explicitly specifying columns, then we check for if we have invisible fields if yes then we reset the whole record, Why ? Because first we want hidden columns to get default/null value. Second thing auto_increment has property no default and no null which voilates invisible key rule 2, And because of this it was giving error. Reseting table->record[0] eliminates this issue. More info put breakpoint on handler::write_row and see auto_increment value. fill_record(m):- we continue loop if we find invisible column because this is already reseted/will get its value if it is default. Test cases:- Since we can not directly add > USER_DEFINED_INVISIBLE column then I have debug_dbug to create it in mysql_prepare_create_table. Patch Credit:- Serg Golubchik
Diffstat (limited to 'sql/lex.h')
-rw-r--r--sql/lex.h1
1 files changed, 1 insertions, 0 deletions
diff --git a/sql/lex.h b/sql/lex.h
index a0068069660..da985ad26a6 100644
--- a/sql/lex.h
+++ b/sql/lex.h
@@ -273,6 +273,7 @@ static SYMBOL symbols[] = {
{ "HAVING", SYM(HAVING)},
{ "HELP", SYM(HELP_SYM)},
{ "HIGH_PRIORITY", SYM(HIGH_PRIORITY)},
+ { "INVISIBLE", SYM(INVISIBLE_SYM)},
{ "HOST", SYM(HOST_SYM)},
{ "HOSTS", SYM(HOSTS_SYM)},
{ "HOUR", SYM(HOUR_SYM)},