Hello, I'm working in implementing UPDATE .. RETURNING. For beginning i'm working on single-table update. I've made parser to parse RETURNING clause in UPDATE. There was a problem that columns that should be updated and columns that should be returned were stored in the same list in lex named item_list. I'm trying now to divide them. Not sure that swapping lists two times during parsing between each other is the best idea. I've implemented primitive returning of result set every time doing an update (even without RETURNING clause) to understand how client understands such response. It successfully returns result set in very simple updates. https://github.com/Mup0c/server/commits/MDEV-5092 -- Miroslav Koberskii
Hi, Мирослав! Another GSoC student is doing INSERT...RETURNING, and for the case of INSERT...SELECT...RETURNING, she has got exactly the same problem of everything being pushed into the select_lex->item_list. We've done list swapping, indeed: --- a/sql/sql_yacc.yy +++ b/sql/sql_yacc.yy @@ -13291,8 +13291,13 @@ insert: Select->set_lock_for_tables($3, true); Lex->current_select= Lex->first_select_lex(); } - insert_field_spec opt_insert_update opt_select_expressions_ins + insert_field_spec opt_insert_update { + Lex->returning_list.swap(Select->item_list); + } + opt_select_expressions + { + Lex->returning_list.swap(Select->item_list); Lex->pop_select(); //main select if (Lex->check_main_unit_semantics()) MYSQL_YYABORT; Note, this adds List<Item> returning_list; to LEX, which you might use too. If implementations are compatible, it'd be easier to put them eventually together into the same code base. Are you on Zulip? See the topic "GSoC ... RETURNING" on the general stream. Your project is very related, so it might be good to follow what the other student is doing. Swapping the lists, by the way, is not the _best_ idea, I think. But we agreed it's the easiest from "good enough" ideas. After the feature is completely implemented, this could be improved. On the other hand, doing the best idea now, could fail the whole project. On Jun 10, Мирослав Коберский wrote:
Hello, I'm working in implementing UPDATE .. RETURNING. For beginning i'm working on single-table update. I've made parser to parse RETURNING clause in UPDATE. There was a problem that columns that should be updated and columns that should be returned were stored in the same list in lex named item_list. I'm trying now to divide them. Not sure that swapping lists two times during parsing between each other is the best idea. I've implemented primitive returning of result set every time doing an update (even without RETURNING clause) to understand how client understands such response. It successfully returns result set in very simple updates.
Regards, Sergei Chief Architect MariaDB and security@mariadb.org
participants (2)
-
Sergei Golubchik -
Мирослав Коберский