maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

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.
> 
> https://github.com/Mup0c/server/commits/MDEV-5092

Regards,
Sergei
Chief Architect MariaDB
and security@xxxxxxxxxxx