Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-8343

Support table function declarations in the parser

Details

    • Task
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • N/A
    • OTHER
    • None

    Description

      This is a part of dj's GSoC project.

      Make the parser support

      CREATE FUNCTION ... RETURNS TABLE table_name (column type [, column type ...])
      <<function body>>

      This is just about supporting it in the parser. The statement should

      • be parsed successfully
      • Instead of creating an SP, return an ER_NOT_SUPPORTED_YET error.

      Attachments

        Issue Links

          Activity

            dj diwas joshi added a comment -

            This task required making some changes under sf_tail in sql_yacc, which has been done. Currently the input is parsing successfully and parser is returning ER_NOT_SUPPORTED_YET error for now, which will be removed later.

            dj diwas joshi added a comment - This task required making some changes under sf_tail in sql_yacc, which has been done. Currently the input is parsing successfully and parser is returning ER_NOT_SUPPORTED_YET error for now, which will be removed later.

            Ok I have tried and at least one example works:

            MariaDB [test]> CREATE FUNCTION f1 (col1 INT) RETURNS TABLE t1 (col1 INT) BEGIN set @a=3; end ; |
            ERROR 1064 (42000): This version of MariaDB doesn't yet support '%s' near 'BEGIN set @a=3; end' at line 1

            (the error text is bad but it doesnt matter because the error will be removed anyway)

            psergei Sergei Petrunia added a comment - Ok I have tried and at least one example works: MariaDB [test]> CREATE FUNCTION f1 (col1 INT) RETURNS TABLE t1 (col1 INT) BEGIN set @a=3; end ; | ERROR 1064 (42000): This version of MariaDB doesn't yet support '%s' near 'BEGIN set @a=3; end' at line 1 (the error text is bad but it doesnt matter because the error will be removed anyway)

            I am looking at the part of changes3.diff that relates to this MDEV, and I am seeing this change;

            type_with_opt_collate was:

            type_with_opt_collate:
                    field_type opt_collate

            and now it is

            type_with_opt_collate:
                      field_type opt_collate
                    | TABLE_SYM ident '(' field_list ')'

            You did it, because sf_tail rule refers to type_with_opt_collate. This is reasonable, sf_tail is used for handling CREATE FUNCTION syntax, and we want to change the grammar there.

            However, type_with_opt_collate is also used in other rules:

            sp_param_name_and_type:
                      ident
                      type_with_opt_collate
             
            sp_decl:
                      DECLARE_SYM sp_decl_idents
                      type_with_opt_collate
                      sp_opt_default

            As far as I understand, these are used for declaring SP parameters and for variable declarations inside stored procedures. That is, your patch also enables things like:

            CREATE PROCEDURE f1 (IN col1 TABLE foo (c2 INT)) BEGIN RETURN '123'; end ; |

            which we don't want. Please change the grammar to not allow anything extra.

            psergei Sergei Petrunia added a comment - I am looking at the part of changes3.diff that relates to this MDEV, and I am seeing this change; type_with_opt_collate was: type_with_opt_collate: field_type opt_collate and now it is type_with_opt_collate: field_type opt_collate | TABLE_SYM ident '(' field_list ')' You did it, because sf_tail rule refers to type_with_opt_collate. This is reasonable, sf_tail is used for handling CREATE FUNCTION syntax, and we want to change the grammar there. However, type_with_opt_collate is also used in other rules: sp_param_name_and_type: ident type_with_opt_collate   sp_decl: DECLARE_SYM sp_decl_idents type_with_opt_collate sp_opt_default As far as I understand, these are used for declaring SP parameters and for variable declarations inside stored procedures. That is, your patch also enables things like: CREATE PROCEDURE f1 (IN col1 TABLE foo (c2 INT)) BEGIN RETURN '123'; end ; | which we don't want. Please change the grammar to not allow anything extra.

            Please also

            • make a separate patch that only covers this MDEV.
            • The patch should include testcases. Check out tests in mysql-test/t.
              • you can take mysql-test/t/sp.test as an example
              • look for "--error" directive how to make the test expect that statement will fail with a certain error
            psergei Sergei Petrunia added a comment - Please also make a separate patch that only covers this MDEV. The patch should include testcases. Check out tests in mysql-test/t. you can take mysql-test/t/sp.test as an example look for "--error" directive how to make the test expect that statement will fail with a certain error

            Patch pushed into dj's tree. Marking as closed

            psergei Sergei Petrunia added a comment - Patch pushed into dj 's tree. Marking as closed

            People

              Unassigned Unassigned
              psergei Sergei Petrunia
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.