← Back to team overview

maria-developers team mailing list archive

Re: Please review MDEV-10030 sql_yacc.yy: Split table_expression and remove PROCEDURE from create_select, select_paren_derived, select_derived2, query_specification

 

Hi, Alexander!

Sure, that's ok. A couple of comments below:

On May 05, Alexander Barkov wrote:
> diff --git a/sql/sql_select.cc b/sql/sql_select.cc
> index a6bbfc8..0d8bfb3 100644
> --- a/sql/sql_select.cc
> +++ b/sql/sql_select.cc
> @@ -988,6 +988,7 @@ JOIN::prepare(TABLE_LIST *tables_init,
>      }
>      if (thd->lex->derived_tables)
>      {
> +      // SELECT 1 FROM (SELECT 1) a PROCEDURE ANALYSE()

What does that mean? An example of a query that is not covered by your
current refactoring and still needs this check?

>        my_error(ER_WRONG_USAGE, MYF(0), "PROCEDURE", 
>                 thd->lex->derived_tables & DERIVED_VIEW ?
>                 "view" : "subquery"); 
> diff --git a/sql/sql_yacc.yy b/sql/sql_yacc.yy
> index 5e1f5dc..445f986 100644
> --- a/sql/sql_yacc.yy
> +++ b/sql/sql_yacc.yy
> @@ -5695,7 +5695,10 @@ create_select:
>            {
>              Select->parsing_place= NO_MATTER;
>            }
> -          table_expression
> +          opt_table_expression
> +          opt_order_clause
> +          opt_limit_clause
> +          opt_select_lock_type
>            {

Looks like you might want to create a rule for that:

  opt_xxx: opt_table_expression opt_order_clause opt_limit_clause
           opt_select_lock_type;

because it seems to be used many times in different parts of the grammar

Regards,
Sergei
Chief Architect MariaDB
and security@xxxxxxxxxxx


Follow ups

References