- developers - lists.mariadb.org

Re: [Maria-developers] [Commits] 62021f3: MDEV-12070 - Introduce thd_query_safe() from MySQL 5.7
by Sergei Golubchik 23 Jun '17

23 Jun '17

Hi, Sergey! On Jun 22, Sergey Vojtovich wrote: > revision-id: 62021f391a42c5577190aa43cb8ad91e56235b46 (mariadb-10.2.6-57-g62021f3) > parent(s): 557e1bd472612848a42e772c1fb6f8ed32ab33b4 > committer: Sergey Vojtovich > timestamp: 2017-06-22 17:15:10 +0400 > message: > > MDEV-12070 - Introduce thd_query_safe() from MySQL 5.7 > > Merged relevant part of MySQL revision: > https://github.com/mysql/mysql-server/commit/565d20b44f24fcc855dc616164d87b… > > diff --git a/sql/sql_class.cc b/sql/sql_class.cc > index f8cf829..db65eb3 100644 > --- a/sql/sql_class.cc > +++ b/sql/sql_class.cc > @@ -4529,6 +4529,32 @@ extern "C" LEX_STRING * thd_query_string (MYSQL_THD thd) > return(&thd->query_string.string); > } > > + > +/** > + Get the current query string for the thread. > + > + @param thd The MySQL internal thread pointer > + @param buf Buffer where the query string will be copied > + @param buflen Length of the buffer > + > + @return Length of the query > + > + @note This function is thread safe as the query string is > + accessed under mutex protection and the string is copied > + into the provided buffer. @see thd_query_string(). > +*/ > + > +extern "C" size_t thd_query_safe(MYSQL_THD thd, char *buf, size_t buflen) > +{ > + mysql_mutex_lock(&thd->LOCK_thd_data); > + size_t len= MY_MIN(buflen - 1, thd->query_length()); > + memcpy(buf, thd->query(), len); > + mysql_mutex_unlock(&thd->LOCK_thd_data); > + buf[len]= '\0'; > + return len; > +} Okay. But as neither thd_query_string() nor thd_query() are part of the plugin API, I'd suggest to remove them, they're inherently unsafe and should not be used. Few other engines use thd_query_string() need to be fixed too (but they bypass the plugin API and we don't promise stability for internal functions). Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

2 2

Re: [Maria-developers] [Commits] 922f970: MDEV-12882 - Assertion failed in MDL_context::upgrade_shared_lock
by Sergei Golubchik 23 Jun '17

23 Jun '17

Hi, Sergey! On Jun 22, Sergey Vojtovich wrote: > revision-id: 922f9700a7fb084e3f7d6cff56e27e24fc603ed7 (mariadb-10.2.6-58-g922f970) > parent(s): 62021f391a42c5577190aa43cb8ad91e56235b46 > committer: Sergey Vojtovich > timestamp: 2017-06-22 17:35:36 +0400 > message: > > MDEV-12882 - Assertion failed in MDL_context::upgrade_shared_lock > > Relaxed assertion (in MySQL it was removed). > For "LOCK TABLES t1 WRITE CONCURRENT, t1 READ" upgrade lock to weakest > existing suitable lock, which is MDL_SHARED_NO_READ_WRITE. > > diff --git a/mysql-test/t/mdl.test b/mysql-test/t/mdl.test > new file mode 100644 > index 0000000..5a74ae5 > --- /dev/null > +++ b/mysql-test/t/mdl.test > @@ -0,0 +1,15 @@ Hm. I'd totally expect main.mdl test to exist for years :) > diff --git a/sql/sql_parse.cc b/sql/sql_parse.cc > index 412cd1d..7c910e8 100644 > --- a/sql/sql_parse.cc > +++ b/sql/sql_parse.cc > @@ -2787,6 +2787,7 @@ static bool lock_tables_open_and_lock_tables(THD *thd, TABLE_LIST *tables) > ! table->prelocking_placeholder && > table->table->file->lock_count() == 0) > { > + enum enum_mdl_type lock_type; > /* > In case when LOCK TABLE ... READ LOCAL was issued for table with > storage engine which doesn't support READ LOCAL option and doesn't > @@ -2799,9 +2800,12 @@ static bool lock_tables_open_and_lock_tables(THD *thd, TABLE_LIST *tables) > deadlock_handler.init(); > thd->push_internal_handler(&deadlock_handler); > > + lock_type= table->table->mdl_ticket->get_type() == MDL_SHARED_WRITE ? > + MDL_SHARED_NO_READ_WRITE : MDL_SHARED_READ_ONLY; > + > bool result= thd->mdl_context.upgrade_shared_lock( > table->table->mdl_ticket, > - MDL_SHARED_READ_ONLY, > + lock_type, > thd->variables.lock_wait_timeout); This only works if you lock WRITE, then READ. If you do it the other way around, you'll get an error. Isn't it inconsistent? Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

2 1

[Maria-developers] Condition pushdown into derived tables and outer joins.
by Sergey Petrunia 23 Jun '17

23 Jun '17

Hello Igor, While reviewing MDEV-12845, I've found this piece in sql_select.cc: while ((tbl= li++)) { /* Do not push conditions from where into materialized inner tables of outer joins: this is not valid. */ if (tbl->is_materialized_derived()) { /* Do not push conditions from where into materialized inner tables of outer joins: this is not valid. */ if (!tbl->is_inner_table_of_outer_join()) Q1: Is int meaningful to have two identical comments? Q2: It is not valid push parts of WHERE, but it is valid to push the parts of ON expression. An example: explain format=json select * from t21 LEFT JOIN (select a,b, COUNT(*) as CNT from t22 group by a,b) TBL ON (t21.a=TBL.a AND TBL.a<5); here, "TBL.a<5" can be pushed down into the subquery, but it is not. EXPLAIN EXTENDED confirms it: "query_block": { "select_id": 1, "const_condition": "1", "table": { "table_name": "t21", "access_type": "ALL", "rows": 10, "filtered": 100 }, "table": { "table_name": "<derived2>", "access_type": "ref", "possible_keys": ["key0"], "key": "key0", "key_length": "5", "used_key_parts": ["a"], "ref": ["test.t21.a"], "rows": 2, "filtered": 100, "attached_condition": "trigcond(trigcond(t21.a < 5 and t21.a is not null))", "materialized": { "query_block": { "select_id": 2, "filesort": { "sort_key": "t22.a, t22.b", "temporary_table": { "table": { "table_name": "t22", "access_type": "ALL", "rows": 10, "filtered": 100 } } } } } } Just in case, the commands to create the dataset were: create table ten(a int); insert into ten values (0),(1),(2),(3),(4),(5),(6),(7),(8),(9); create table t21 (a int, b int, c int); insert into t21 select a,a,a from ten; create table t22 (a int, b int, c int); insert into t22 select a,a,a from ten; BR Sergei -- Sergei Petrunia, Software Developer MariaDB Corporation | Skype: sergefp | Blog: http://s.petrunia.net/blog

1 0

[Maria-developers] Project Progress Report [Week 3]
by ANKIT KUMAR 20 Jun '17

20 Jun '17

Hi, In this week, we worked on in-memory structures:- Which representation to choose(prefix or expression tree), How to store values and how authentication will be done. I have prepared pseudocode to implement this subtask and have made implemented some part of code. Hopefully by 25th May, I will finish off with >50% of the project. I will declare Phase-2 deliverables next Monday(26 May). Kind regards, Ankit Kumar

2 1

Re: [Maria-developers] MDEV-12620 - set lock_wait_timeout = 1; flush tables with read lock;
by Sergei Golubchik 16 Jun '17

16 Jun '17

Hi, Sergey! On Jun 16, Sergey Vojtovich wrote: > revision-id: 056bab0880544d91ea67d18fe8db65b4f6625482 (mariadb-10.1.24-22-g056bab0) > parent(s): 58f87a41bd8de7370cc05c41977fadc685826c9e > committer: Sergey Vojtovich > timestamp: 2017-06-16 15:47:46 +0400 > message: > > MDEV-12620 - set lock_wait_timeout = 1;flush tables with read lock; > lock not released after timeout > > Release GRL if FLUSH TABLES phase failed. > > diff --git a/mysql-test/t/mdl_sync.test b/mysql-test/t/mdl_sync.test > index 8e80978..c479c2a 100644 > --- a/mysql-test/t/mdl_sync.test > +++ b/mysql-test/t/mdl_sync.test > @@ -4806,6 +4806,30 @@ disconnect con2; > disconnect con3; > > +--echo # > +--echo # MDEV-12620 - set lock_wait_timeout = 1;flush tables with read lock; > +--echo # lock not released after timeout > +--echo # > +CREATE TABLE t1(a INT) ENGINE=InnoDB; > +SET debug_sync='open_tables_after_open_and_process_table SIGNAL ready WAIT_FOR go'; > +send SELECT * FROM t1; > + > +connect (con1,localhost,root,,); > +SET debug_sync='now WAIT_FOR ready'; > +# lock_wait_timeout should be 0 in 10.3, so that we don't have to wait at all what's special in 10.3? > +SET lock_wait_timeout=1; > +--error ER_LOCK_WAIT_TIMEOUT > +FLUSH TABLES WITH READ LOCK; > +SET debug_sync='now SIGNAL go'; > + > +connection default; > +reap; > +SET debug_sync='RESET'; > +DROP TABLE t1; What should happen without a bug fix? DROP TABLE hangs? > + > +disconnect con1; > + > # Check that all connections opened by test cases in this file are really > # gone so execution of other tests won't be affected by their presence. > --source include/wait_until_count_sessions.inc > diff --git a/sql/sql_reload.cc b/sql/sql_reload.cc > index 376dfeb..d68ce96 100644 > --- a/sql/sql_reload.cc > +++ b/sql/sql_reload.cc > @@ -253,7 +253,8 @@ bool reload_acl_and_cache(THD *thd, unsigned long long options, > NOTE: my_error() has been already called by reopen_tables() within > close_cached_tables(). > */ > - result= 1; > + thd->global_read_lock.unlock_global_read_lock(thd); > + return 1; > } Sure. Looks correct. Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

2 1

[Maria-developers] MDEV-10306 Wrong results with combination of CONCAT, SUBSTR and CONVERT in subquery
by Alexander Barkov 16 Jun '17

16 Jun '17

Hello Sergei, Please review a fix for MDEV-10306. Thanks!

4 13

Re: [Maria-developers] [Commits] 01b2bb79bb78e42108e32af02f1418a660ca861d Fixed the bug mdev-13064.
by Oleksandr Byelkin 16 Jun '17

16 Jun '17

Hi, Igor! Am 15.06.2017 um 23:43 schrieb Igor Babaev: > commit 01b2bb79bb78e42108e32af02f1418a660ca861d > Author: Igor Babaev <igor(a)askmonty.org> > Commit: Igor Babaev <igor(a)askmonty.org> > > Fixed the bug mdev-13064. > > This is another attempt to fix the bug mdev-12992. > This patch introduces st_select_lex::context_analysis_place for > the place in SELECT where context analysis is currently performed. > It's similar to st_select_lex::parsing_place, but it is used at It is OK to push. > the preparation stage. > --- > mysql-test/r/func_group.result | 9 +++++++++ > mysql-test/t/func_group.test | 13 +++++++++++++ > sql/item.cc | 5 ++--- > sql/item_windowfunc.cc | 2 +- > sql/sql_lex.h | 1 + > sql/sql_select.cc | 33 ++++++++++++++++++--------------- > 6 files changed, 44 insertions(+), 19 deletions(-) > > diff --git a/mysql-test/r/func_group.result b/mysql-test/r/func_group.result > index cb97ea2..c4e991e 100644 > --- a/mysql-test/r/func_group.result > +++ b/mysql-test/r/func_group.result > @@ -2447,3 +2447,12 @@ DROP TABLE t1; > # > # End of 10.1 tests > # > +# > +# MDEV-13064: assertion `n < m_size' fails in Item::split_sum_func2() > +# > +create table t1 (i int) engine=MyISAM; > +insert into t1 value (1),(2); > +select count(*)+sleep(0) from t1; > +count(*)+sleep(0) > +2 > +drop table t1; > diff --git a/mysql-test/t/func_group.test b/mysql-test/t/func_group.test > index 1e75099..8bbc9e6 100644 > --- a/mysql-test/t/func_group.test > +++ b/mysql-test/t/func_group.test > @@ -1691,3 +1691,16 @@ DROP TABLE t1; > --echo # > --echo # End of 10.1 tests > --echo # > + > +--echo # > +--echo # MDEV-13064: assertion `n < m_size' fails in Item::split_sum_func2() > +--echo # > + > +create table t1 (i int) engine=MyISAM; > +insert into t1 value (1),(2); > + > +select count(*)+sleep(0) from t1; > + > +drop table t1; > + > + > diff --git a/sql/item.cc b/sql/item.cc > index 8db5cfc..df615b5 100644 > --- a/sql/item.cc > +++ b/sql/item.cc > @@ -490,8 +490,7 @@ int Item::save_str_value_in_field(Field *field, String *result) > command => we should check thd->lex->current_select on zero (thd->lex > can be uninitialised) > */ > - if (thd->lex->current_select && > - thd->stmt_arena->is_stmt_prepare_or_first_sp_execute()) > + if (thd->lex->current_select) > { > enum_parsing_place place= > thd->lex->current_select->parsing_place; > @@ -5513,7 +5512,7 @@ bool Item_field::fix_fields(THD *thd, Item **reference) > > SELECT_LEX *select= thd->lex->current_select; > thd->change_item_tree(reference, > - select->parsing_place == IN_GROUP_BY && > + select->context_analysis_place == IN_GROUP_BY && > alias_name_used ? *rf->ref : rf); > > /* > diff --git a/sql/item_windowfunc.cc b/sql/item_windowfunc.cc > index 59a22c6..27b0072 100644 > --- a/sql/item_windowfunc.cc > +++ b/sql/item_windowfunc.cc > @@ -71,7 +71,7 @@ > { > DBUG_ASSERT(fixed == 0); > > - enum_parsing_place place= thd->lex->current_select->parsing_place; > + enum_parsing_place place= thd->lex->current_select->context_analysis_place; > > if (!(place == SELECT_LIST || place == IN_ORDER_BY)) > { > diff --git a/sql/sql_lex.h b/sql/sql_lex.h > index face3bc..0c55ffc 100644 > --- a/sql/sql_lex.h > +++ b/sql/sql_lex.h > @@ -855,6 +855,7 @@ class st_select_lex: public st_select_lex_node > /* reserved for exists 2 in */ > uint select_n_reserved; > enum_parsing_place parsing_place; /* where we are parsing expression */ > + enum_parsing_place context_analysis_place; /* where we are in prepare */ > bool with_sum_func; /* sum function indicator */ > > ulong table_join_options; > diff --git a/sql/sql_select.cc b/sql/sql_select.cc > index 4c64cf2..6c56f01 100644 > --- a/sql/sql_select.cc > +++ b/sql/sql_select.cc > @@ -648,17 +648,15 @@ void remove_redundant_subquery_clauses(st_select_lex *subq_select_lex) > > thd->lex->allow_sum_func|= (nesting_map)1 << select->nest_level; > > - save_place= thd->lex->current_select->parsing_place; > - thd->lex->current_select->parsing_place= IN_ORDER_BY; > + save_place= thd->lex->current_select->context_analysis_place; > + thd->lex->current_select->context_analysis_place= IN_ORDER_BY; > res= res || setup_order(thd, ref_pointer_array, tables, fields, all_fields, > order); > - thd->lex->current_select->parsing_place= save_place; > - thd->lex->allow_sum_func&= ~((nesting_map)1 << select->nest_level); > - save_place= thd->lex->current_select->parsing_place; > - thd->lex->current_select->parsing_place= IN_GROUP_BY; > + thd->lex->allow_sum_func&= ~((nesting_map)1 << select->nest_level); > + thd->lex->current_select->context_analysis_place= IN_GROUP_BY; > res= res || setup_group(thd, ref_pointer_array, tables, fields, all_fields, > group, hidden_group_fields); > - thd->lex->current_select->parsing_place= save_place; > + thd->lex->current_select->context_analysis_place= save_place; > thd->lex->allow_sum_func|= (nesting_map)1 << select->nest_level; > res= res || setup_windows(thd, ref_pointer_array, tables, fields, all_fields, > win_specs, win_funcs); > @@ -712,6 +710,7 @@ void remove_redundant_subquery_clauses(st_select_lex *subq_select_lex) > if (select_lex->handle_derived(thd->lex, DT_PREPARE)) > DBUG_RETURN(1); > > + thd->lex->current_select->context_analysis_place= NO_MATTER; > thd->lex->current_select->is_item_list_lookup= 1; > /* > If we have already executed SELECT, then it have not sense to prevent > @@ -801,12 +800,13 @@ void remove_redundant_subquery_clauses(st_select_lex *subq_select_lex) > > ref_ptrs= ref_ptr_array_slice(0); > > - enum_parsing_place save_place= thd->lex->current_select->parsing_place; > - thd->lex->current_select->parsing_place= SELECT_LIST; > + enum_parsing_place save_place= > + thd->lex->current_select->context_analysis_place; > + thd->lex->current_select->context_analysis_place= SELECT_LIST; > if (setup_fields(thd, ref_ptrs, fields_list, MARK_COLUMNS_READ, > &all_fields, 1)) > DBUG_RETURN(-1); > - thd->lex->current_select->parsing_place= save_place; > + thd->lex->current_select->context_analysis_place= save_place; > > if (setup_without_group(thd, ref_ptrs, tables_list, > select_lex->leaf_tables, fields_list, > @@ -22235,14 +22235,16 @@ int setup_order(THD *thd, Ref_ptr_array ref_pointer_array, TABLE_LIST *tables, > List<Item> &fields, List<Item> &all_fields, ORDER *order, > bool from_window_spec) > { > - enum_parsing_place parsing_place= thd->lex->current_select->parsing_place; > + enum_parsing_place context_analysis_place= > + thd->lex->current_select->context_analysis_place; > thd->where="order clause"; > for (; order; order=order->next) > { > if (find_order_in_list(thd, ref_pointer_array, tables, order, fields, > all_fields, FALSE, from_window_spec)) > return 1; > - if ((*order->item)->with_window_func && parsing_place != IN_ORDER_BY) > + if ((*order->item)->with_window_func && > + context_analysis_place != IN_ORDER_BY) > { > my_error(ER_WINDOW_FUNCTION_IN_WINDOW_SPEC, MYF(0)); > return 1; > @@ -22284,7 +22286,8 @@ int setup_order(THD *thd, Ref_ptr_array ref_pointer_array, TABLE_LIST *tables, > List<Item> &fields, List<Item> &all_fields, ORDER *order, > bool *hidden_group_fields, bool from_window_spec) > { > - enum_parsing_place parsing_place= thd->lex->current_select->parsing_place; > + enum_parsing_place context_analysis_place= > + thd->lex->current_select->context_analysis_place; > *hidden_group_fields=0; > ORDER *ord; > > @@ -22300,14 +22303,14 @@ int setup_order(THD *thd, Ref_ptr_array ref_pointer_array, TABLE_LIST *tables, > all_fields, TRUE, from_window_spec)) > return 1; > (*ord->item)->marker= UNDEF_POS; /* Mark found */ > - if ((*ord->item)->with_sum_func && parsing_place == IN_GROUP_BY) > + if ((*ord->item)->with_sum_func && context_analysis_place == IN_GROUP_BY) > { > my_error(ER_WRONG_GROUP_FIELD, MYF(0), (*ord->item)->full_name()); > return 1; > } > if ((*ord->item)->with_window_func) > { > - if (parsing_place == IN_GROUP_BY) > + if (context_analysis_place == IN_GROUP_BY) > my_error(ER_WRONG_PLACEMENT_OF_WINDOW_FUNCTION, MYF(0)); > else > my_error(ER_WINDOW_FUNCTION_IN_WINDOW_SPEC, MYF(0)); > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits

1 0

[Maria-developers] Review for MDEV-12666: CURRENT_ROLE() and DATABASE() does not work in a view
by Alexander Barkov 13 Jun '17

13 Jun '17

Hi Vicentiu, The patch looks fine. Thanks! I have only small comments below: > > [Commits] 974064cde3c: MDEV-12666: CURRENT_ROLE() and DATABASE() does not work in a view > vicentiu vicentiu at mariadb.org > Thu Jun 8 10:11:38 EEST 2017 > > Previous message (by thread): [Commits] 7f2d3c3: MDEV-11084 Select statement with partition selection against MyISAM table opens all partitions. > Next message (by thread): [Commits] d03abc71a49: MDEV-12609: Allow suppression of InnoDB log messages about reserving extents > Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] > > revision-id: 974064cde3c1cd1be9157bc11ce410604807f68b (mariadb-10.0.31-2-g974064cde3c) > parent(s): 54cd5bc703da08be45894495d7f3e2c8117617cd > author: Vicențiu Ciorbaru > committer: Vicențiu Ciorbaru > timestamp: 2017-06-08 10:10:07 +0300 > message: > > MDEV-12666: CURRENT_ROLE() and DATABASE() does not work in a view > > The problem lies in how CURRENT_ROLE is defined. The > Item_func_current_role inherits from Item_func_sysconst, which defines > a safe_charset_converter to be a const_charset_converter. > > During view creation, if there is no role previously set, the current_role() > function returns NULL. > > This is captured on item instantiation and the > const_charset_converter call subsequently returns an Item_null. > In turn, the function is replaced with Item_null and the view is > then created with an Item_null instead of Item_func_current_role. > > Without this patch, the first SHOW CREATE VIEW from the testcase would > have a where clause of WHERE role_name = NULL, while the second SHOW > CREATE VIEW would show a correctly created view. > > The same applies for the DATABASE function, as it can change as well. > > There is an additional problem with CURRENT_ROLE() when used in a > prepared statement. During prepared statement creation we used to set > the string_value of the function to the current role as well as the > null_value flag. During execution, if CURRENT_ROLE was not null, the > null_value flag was never set to not-null during fix_fields. > > Item_func_current_user however can never be NULL so it did not show this > problem in a view before. At the same time, the CURRENT_USER() can not > be changed between prepared statement execution and creation so the > implementation where the value is stored during fix_fields is > sufficient. > > Note also that DATABASE() function behaves differently during prepared > statements. See bug 25843 for details or commit > 7e0ad09edff587dadc3e9855fc81e1b7de8f2199 > <cut> > --- a/sql/item_strfunc.cc > +++ b/sql/item_strfunc.cc > @@ -2344,6 +2344,7 @@ String *Item_func_database::val_str(String *str) > } > else > str->copy(thd->db, thd->db_length, system_charset_info); > + null_value= 0; > return str; > } > > @@ -2378,6 +2379,30 @@ bool Item_func_user::init(const char *user, const char *host) > } > > > +Item *Item_func_sysconst::safe_charset_converter(CHARSET_INFO *tocs) > +{ > + /* > + During view or prepared statement creation, the item should not > + make use of const_charset_converter as it would imply substitution > + with constant items which is not correct. Functions can have different > + values during view creation and view execution based on context. > + > + Return the identical item during view creation and prepare. > + */ > + if (current_thd->lex->context_analysis_only & > + (CONTEXT_ANALYSIS_ONLY_PREPARE | CONTEXT_ANALYSIS_ONLY_VIEW)) > + return this; > + return const_charset_converter(tocs, true, fully_qualified_func_name()); I propose to avoid code duplication and do like this: if (!Item_func_sysconst::const_item()) return this; return return const_charset_converter(tocs, true, fully_qualified_func_name()); > +} > + > +bool Item_func_sysconst::const_item() const > +{ > + if (current_thd->lex->context_analysis_only & > + (CONTEXT_ANALYSIS_ONLY_PREPARE | CONTEXT_ANALYSIS_ONLY_VIEW)) > + return false; > + return true; > +} > + > bool Item_func_user::fix_fields(THD *thd, Item **ref) > { > return (Item_func_sysconst::fix_fields(thd, ref) || > @@ -2403,20 +2428,25 @@ bool Item_func_current_role::fix_fields(THD *thd, Item **ref) > > Security_context *ctx= context->security_ctx > ? context->security_ctx : thd->security_ctx; > - > if (ctx->priv_role[0]) > { > if (str_value.copy(ctx->priv_role, strlen(ctx->priv_role), > system_charset_info)) > return 1; > - > str_value.mark_as_const(); > + null_value= maybe_null= 0; > return 0; > } > null_value= maybe_null= 1; > return 0; > } > > +String* Item_func_current_role::val_str(String * str) > +{ > + DBUG_ASSERT(fixed == 1); > + return null_value ? NULL : &str_value; > +} > + Why did you move val_str() from *.h to *.cc ? The method is just two lines, I'd leave it in *.h <cut>

1 0

[Maria-developers] MDEV-12962 Testing MDEV-10142
by Alexander Barkov 13 Jun '17

13 Jun '17

Hi Andrii, Thanks for looking into this. Please find my comments inline: > > > Below are mostly minor notes for which clarification is needed. > > Conceptual: are we sure that ORACLE mode should invalidate native MariaDB constructs? We need some consistency and in my understanding following should still work in Oracle mode: > ELSE / ELSEIF > % operation (if possible) I'm not sure. Monty, what do you think? > > > 2. MDEV-10343 sql_mode=ORACLE: Providing compatibility for basic SQL data types > > following are valid build-in datatypes declaration in oracle which cause syntax error at the moment (needs to be documented or created another task): > > these probably had to be implemented inside MDEV-10343 > > create or replace table t1(a binary_float); > create or replace table t1(a binary_double); > create or replace table t1(a long raw); > create or replace table t1(a NCLOB); > these need more effort or maybe just must be documented or separate task is needed > create or replace table t1(a varchar(30 byte)); > create or replace table t1(a varchar(30 char)); > create or replace table t1(a timestamp with local time zone); > create or replace table t1(a timestamp with time zone); > create or replace table t1(a interval day); > create or replace table t1(a interval year); > create or replace table t1(a BFILE); > create or replace table t1(a rowid); > create or replace table t1(a urowid(5)); > this should give an error (oracle will return ORA-02017: integer value required ) > MariaDB [test]> create or replace table t1(a number(2.2)); > Query OK, 0 rows affected (0.24 sec) There is a task for TIMESTAMP WITH TIME ZONE: MDEV-10018 Timestamp with time zone For other data types, should we create one task for every data type? > > > 3. MDEV-10411 Providing compatibility for basic PL/SQL constructs > 3.6 Assignment operator > It doesn't sound intuitive that one may write "wait_timeout:=a", but "a:=wait_timeout" shows syntax error. > > begin declare a int; begin a:=wait_timeout; end; end;; One needs to use @ when referring a system variable in the right side: a:=@wait_timeout; It's the same in the default mode: SET wait_timeount=100; but: SET xxx=@wait_timeout; Not sure if we should do anything with that. > > > 3.7 Variable declarations > Oracle allows NOT NULL in variable declaration. Maybe we should allow that syntax as well? > > begin declare a NOT NULL int; begin a:=1; a:=NULL; end; end;; I have created a task for this: MDEV-13078 NOT NULL routine variables > > > 10. MDEV-10585 EXECUTE IMMEDIATE > In ORACLE the command supports 'RETURNING INTO' clause, we should probably document the difference? > > sql_stmt := 'UPDATE emp SET sal = 2000 WHERE empno = :1 > > RETURNING sal INTO :2'; > > EXECUTE IMMEDIATE sql_stmt USING emp_id RETURNING INTO salary; In Oracle, EXECUTE IMMEDIATE also has the "INTO" clause: sql_stmt := 'SELECT * FROM emp WHERE empno = :id'; EXECUTE IMMEDIATE sql_stmt INTO emp_rec USING emp_id; Should we create two new tasks, for RETURNING INTO, and for INTO? > > 12. MDEV-10588 TRUNCATE TABLE t1 DROP|REUSE STORAGE > Following clauses should be allowed in TRUNCATE command as well: > [ PRESERVE MATERIALIZED VIEW LOG | PURGE MATERIALIZED VIEW LOG ] Should we create a task to ignore this syntax? > > 18. MDEV-10577 sql_mode=ORACLE: %TYPE in variable declarations > It is not clear what is expected to happen if table's column definition is altered after stored program creation. Nothing. Data type resolution is done during execution.

1 0

[Maria-developers] Progress report of the Project[Week 2]
by ANKIT KUMAR 12 Jun '17

12 Jun '17

Hi, In this week, I managed to do few contributions and finally completed subtask-1. These are few things that I did this week- 1. Extended CREATE USER syntax- Now there will be multiple authentication mechanisms per user. 2. Created tests for the newly implemented syntax and some tests for previously existing functonalities. Need to give final touch up to the code and will commit tomorrow. Now I will proceed to subtask-2 Week-3[TODO's]- 1. Implement in-memory structures for this new syntax-[Providing it to ACL_USER] 2. Will be able to write data in memory(By the end of Phase-1 evaluation). Kind regards, Ankit Kumar.

1 0