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

PROCEDURE and anonymous blocks silently ignore FETCH GROUP NEXT ROW

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 10.3(EOL), 10.4(EOL)
    • 10.4.4
    • Stored routines
    • None

    Description

      The FETCH GROUP NEXT ROW statement is accepted in various unexpected contexts.

      Procedures

      DELIMITER $$
      		 
      CREATE OR REPLACE PROCEDURE p1()
      		 
      BEGIN
      		 
        FETCH GROUP NEXT ROW;
      		 
      END;
      		 
      $$
      		 
      DELIMITER ;
      		 
      CALL p1;

      It silently compiles and executes the procedure. The FETCH GROUP NEXT ROW is silently ignored.
      It should probably return an error at compile time, like inside a non-aggregate FUNCTION.

      Anonymous blocks

      The same problem is repeatable with anonymous blocks:

      DELIMITER $$
      		 
      BEGIN NOT ATOMIC
      		 
        FETCH GROUP NEXT ROW;
      		 
      END;
      		 
      $$
      		 
      DELIMITER ;

      Non-aggregate functions with DEFINER

      If I add the DEFINER clause into a non-aggregate function, FETCH GROUP NEXT ROW is silently accepted:

      DELIMITER $$
      		 
      CREATE OR REPLACE DEFINER=root@localhost  FUNCTION f1() RETURNS INT
      		 
      BEGIN
      		 
        FETCH GROUP NEXT ROW;
      		 
        RETURN 0;
      		 
      END;
      		 
      $$

      Triggers

      CREATE OR REPLACE TABLE t1 (a INT);
      		 
      CREATE OR REPLACE TRIGGER tr1
      		 
        AFTER INSERT ON t1 FOR EACH ROW 
         FETCH GROUP NEXT ROW;

      Events

      CREATE OR REPLACE EVENT ev1
      		 
        ON SCHEDULE EVERY 1 HOUR
      		 
        STARTS CURRENT_TIMESTAMP + INTERVAL 1 MONTH
      		 
        ENDS CURRENT_TIMESTAMP + INTERVAL 1 MONTH + INTERVAL 1 WEEK
      		 
      DO FETCH GROUP NEXT ROW;

      Package body (10.4.4 only)

      SET sql_mode=ORACLE;
      		 
      DELIMITER $$
      		 
      CREATE OR REPLACE PACKAGE pkg1 AS
      		 
        PROCEDURE p1;
      		 
      END;
      		 
      CREATE OR REPLACE PACKAGE BODY pkg1 AS
      		 
        PROCEDURE p1 AS
      		 
        BEGIN
      		 
          NULL;
      		 
        END;
      		 
      BEGIN
      		 
        FETCH GROUP NEXT ROW;
      		 
      END;
      		 
      $$
      		 
      DELIMITER ;

      Attachments

        Issue Links

          blocks

          Task - A task that needs to be done. MDEV-12518 Unify sql_yacc.yy and sql_yacc_ora.yy

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            bar Alexander Barkov created issue -
            bar Alexander Barkov made changes -
            Field Original Value New Value
            Description I run this script:
            {code:sql}
            DELIMITER $$
            CREATE OR REPLACE PROCEDURE p1()
            BEGIN
              FETCH GROUP NEXT ROW;
            END;
            $$
            DELIMITER ;
            CALL p1;
            {code}
            It silently compiles and executes the procedure. The {{FETCH GROUP NEXT ROW}} is silently ignored.
            It should probably return an error at compile time, like inside a non-aggregate FUNCTION.


            The same problem is repeatable with anonymous blocks:
            {code:sql}
            DELIMITER $$
            BEGIN NOT ATOMIC
              FETCH GROUP NEXT ROW;
            END;
            $$
            DELIMITER ;
            {code}             		I run this script:
            {code:sql}
            DELIMITER $$
            CREATE OR REPLACE PROCEDURE p1()
            BEGIN
              FETCH GROUP NEXT ROW;
            END;
            $$
            DELIMITER ;
            CALL p1;
            {code}
            It silently compiles and executes the procedure. The {{FETCH GROUP NEXT ROW}} is silently ignored.
            It should probably return an error at compile time, like inside a non-aggregate FUNCTION.


            The same problem is repeatable with anonymous blocks:
            {code:sql}
            DELIMITER $$
            BEGIN NOT ATOMIC
              FETCH GROUP NEXT ROW;
            END;
            $$
            DELIMITER ;
            {code}

            If I add the {{DEFINER}} clause into a function, it also silently accepts {{FETCH GROUP NEXT ROW}}:
            {code:sql}
            DELIMITER $$
            CREATE OR REPLACE DEFINER=root@localhost FUNCTION f1() RETURNS INT
            BEGIN
              FETCH GROUP NEXT ROW;
              RETURN 0;
            END;
            $$
            {code}

            bar Alexander Barkov made changes -
            Description I run this script:
            {code:sql}
            DELIMITER $$
            CREATE OR REPLACE PROCEDURE p1()
            BEGIN
              FETCH GROUP NEXT ROW;
            END;
            $$
            DELIMITER ;
            CALL p1;
            {code}
            It silently compiles and executes the procedure. The {{FETCH GROUP NEXT ROW}} is silently ignored.
            It should probably return an error at compile time, like inside a non-aggregate FUNCTION.


            The same problem is repeatable with anonymous blocks:
            {code:sql}
            DELIMITER $$
            BEGIN NOT ATOMIC
              FETCH GROUP NEXT ROW;
            END;
            $$
            DELIMITER ;
            {code}

            If I add the {{DEFINER}} clause into a function, it also silently accepts {{FETCH GROUP NEXT ROW}}:
            {code:sql}
            DELIMITER $$
            CREATE OR REPLACE DEFINER=root@localhost FUNCTION f1() RETURNS INT
            BEGIN
              FETCH GROUP NEXT ROW;
              RETURN 0;
            END;
            $$
            {code}

            		h3. Procedures
            I run this script:
            {code:sql}
            DELIMITER $$
            CREATE OR REPLACE PROCEDURE p1()
            BEGIN
              FETCH GROUP NEXT ROW;
            END;
            $$
            DELIMITER ;
            CALL p1;
            {code}
            It silently compiles and executes the procedure. The {{FETCH GROUP NEXT ROW}} is silently ignored.
            It should probably return an error at compile time, like inside a non-aggregate FUNCTION.

            h3. Anonymous blocks
            The same problem is repeatable with anonymous blocks:
            {code:sql}
            DELIMITER $$
            BEGIN NOT ATOMIC
              FETCH GROUP NEXT ROW;
            END;
            $$
            DELIMITER ;
            {code}

            h3. Non-aggregate functions with DEFINER
            If I add the {{DEFINER}} clause into a function, it also silently accepts {{FETCH GROUP NEXT ROW}}:
            {code:sql}
            DELIMITER $$
            CREATE OR REPLACE DEFINER=root@localhost FUNCTION f1() RETURNS INT
            BEGIN
              FETCH GROUP NEXT ROW;
              RETURN 0;
            END;
            $$
            {code}

            h3. Triggers are also affected:
            {code:sql}
            CREATE OR REPLACE TABLE t1 (a INT);
            CREATE OR REPLACE TRIGGER tr1
              AFTER INSERT ON t1 FOR EACH ROW
               FETCH GROUP NEXT ROW;
            {code}

            h3. Events are also affected:
            {code:sql}
            CREATE OR REPLACE EVENT ev1
              ON SCHEDULE EVERY 1 HOUR
              STARTS CURRENT_TIMESTAMP + INTERVAL 1 MONTH
              ENDS CURRENT_TIMESTAMP + INTERVAL 1 MONTH + INTERVAL 1 WEEK
            DO FETCH GROUP NEXT ROW;
            {code}
            bar Alexander Barkov made changes -
            Description h3. Procedures
            I run this script:
            {code:sql}
            DELIMITER $$
            CREATE OR REPLACE PROCEDURE p1()
            BEGIN
              FETCH GROUP NEXT ROW;
            END;
            $$
            DELIMITER ;
            CALL p1;
            {code}
            It silently compiles and executes the procedure. The {{FETCH GROUP NEXT ROW}} is silently ignored.
            It should probably return an error at compile time, like inside a non-aggregate FUNCTION.

            h3. Anonymous blocks
            The same problem is repeatable with anonymous blocks:
            {code:sql}
            DELIMITER $$
            BEGIN NOT ATOMIC
              FETCH GROUP NEXT ROW;
            END;
            $$
            DELIMITER ;
            {code}

            h3. Non-aggregate functions with DEFINER
            If I add the {{DEFINER}} clause into a function, it also silently accepts {{FETCH GROUP NEXT ROW}}:
            {code:sql}
            DELIMITER $$
            CREATE OR REPLACE DEFINER=root@localhost FUNCTION f1() RETURNS INT
            BEGIN
              FETCH GROUP NEXT ROW;
              RETURN 0;
            END;
            $$
            {code}

            h3. Triggers are also affected:
            {code:sql}
            CREATE OR REPLACE TABLE t1 (a INT);
            CREATE OR REPLACE TRIGGER tr1
              AFTER INSERT ON t1 FOR EACH ROW
               FETCH GROUP NEXT ROW;
            {code}

            h3. Events are also affected:
            {code:sql}
            CREATE OR REPLACE EVENT ev1
              ON SCHEDULE EVERY 1 HOUR
              STARTS CURRENT_TIMESTAMP + INTERVAL 1 MONTH
              ENDS CURRENT_TIMESTAMP + INTERVAL 1 MONTH + INTERVAL 1 WEEK
            DO FETCH GROUP NEXT ROW;
            {code}
            		The {{FETCH GROUP NEXT ROW}} is accepted in various unexpected contexts.

            h3. Procedures
            {code:sql}
            DELIMITER $$
            CREATE OR REPLACE PROCEDURE p1()
            BEGIN
              FETCH GROUP NEXT ROW;
            END;
            $$
            DELIMITER ;
            CALL p1;
            {code}
            It silently compiles and executes the procedure. The {{FETCH GROUP NEXT ROW}} is silently ignored.
            It should probably return an error at compile time, like inside a non-aggregate FUNCTION.

            h3. Anonymous blocks
            The same problem is repeatable with anonymous blocks:
            {code:sql}
            DELIMITER $$
            BEGIN NOT ATOMIC
              FETCH GROUP NEXT ROW;
            END;
            $$
            DELIMITER ;
            {code}

            h3. Non-aggregate functions with DEFINER
            If I add the {{DEFINER}} clause into a non-aggregate function, {{FETCH GROUP NEXT ROW}} is silently accepted:
            {code:sql}
            DELIMITER $$
            CREATE OR REPLACE DEFINER=root@localhost FUNCTION f1() RETURNS INT
            BEGIN
              FETCH GROUP NEXT ROW;
              RETURN 0;
            END;
            $$
            {code}

            h3. Triggers
            {code:sql}
            CREATE OR REPLACE TABLE t1 (a INT);
            CREATE OR REPLACE TRIGGER tr1
              AFTER INSERT ON t1 FOR EACH ROW
               FETCH GROUP NEXT ROW;
            {code}

            h3. Events
            {code:sql}
            CREATE OR REPLACE EVENT ev1
              ON SCHEDULE EVERY 1 HOUR
              STARTS CURRENT_TIMESTAMP + INTERVAL 1 MONTH
              ENDS CURRENT_TIMESTAMP + INTERVAL 1 MONTH + INTERVAL 1 WEEK
            DO FETCH GROUP NEXT ROW;
            {code}
            bar Alexander Barkov made changes -
            Description The {{FETCH GROUP NEXT ROW}} is accepted in various unexpected contexts.

            h3. Procedures
            {code:sql}
            DELIMITER $$
            CREATE OR REPLACE PROCEDURE p1()
            BEGIN
              FETCH GROUP NEXT ROW;
            END;
            $$
            DELIMITER ;
            CALL p1;
            {code}
            It silently compiles and executes the procedure. The {{FETCH GROUP NEXT ROW}} is silently ignored.
            It should probably return an error at compile time, like inside a non-aggregate FUNCTION.

            h3. Anonymous blocks
            The same problem is repeatable with anonymous blocks:
            {code:sql}
            DELIMITER $$
            BEGIN NOT ATOMIC
              FETCH GROUP NEXT ROW;
            END;
            $$
            DELIMITER ;
            {code}

            h3. Non-aggregate functions with DEFINER
            If I add the {{DEFINER}} clause into a non-aggregate function, {{FETCH GROUP NEXT ROW}} is silently accepted:
            {code:sql}
            DELIMITER $$
            CREATE OR REPLACE DEFINER=root@localhost FUNCTION f1() RETURNS INT
            BEGIN
              FETCH GROUP NEXT ROW;
              RETURN 0;
            END;
            $$
            {code}

            h3. Triggers
            {code:sql}
            CREATE OR REPLACE TABLE t1 (a INT);
            CREATE OR REPLACE TRIGGER tr1
              AFTER INSERT ON t1 FOR EACH ROW
               FETCH GROUP NEXT ROW;
            {code}

            h3. Events
            {code:sql}
            CREATE OR REPLACE EVENT ev1
              ON SCHEDULE EVERY 1 HOUR
              STARTS CURRENT_TIMESTAMP + INTERVAL 1 MONTH
              ENDS CURRENT_TIMESTAMP + INTERVAL 1 MONTH + INTERVAL 1 WEEK
            DO FETCH GROUP NEXT ROW;
            {code}
            		The {{FETCH GROUP NEXT ROW}} statement is accepted in various unexpected contexts.

            h3. Procedures
            {code:sql}
            DELIMITER $$
            CREATE OR REPLACE PROCEDURE p1()
            BEGIN
              FETCH GROUP NEXT ROW;
            END;
            $$
            DELIMITER ;
            CALL p1;
            {code}
            It silently compiles and executes the procedure. The {{FETCH GROUP NEXT ROW}} is silently ignored.
            It should probably return an error at compile time, like inside a non-aggregate FUNCTION.

            h3. Anonymous blocks
            The same problem is repeatable with anonymous blocks:
            {code:sql}
            DELIMITER $$
            BEGIN NOT ATOMIC
              FETCH GROUP NEXT ROW;
            END;
            $$
            DELIMITER ;
            {code}

            h3. Non-aggregate functions with DEFINER
            If I add the {{DEFINER}} clause into a non-aggregate function, {{FETCH GROUP NEXT ROW}} is silently accepted:
            {code:sql}
            DELIMITER $$
            CREATE OR REPLACE DEFINER=root@localhost FUNCTION f1() RETURNS INT
            BEGIN
              FETCH GROUP NEXT ROW;
              RETURN 0;
            END;
            $$
            {code}

            h3. Triggers
            {code:sql}
            CREATE OR REPLACE TABLE t1 (a INT);
            CREATE OR REPLACE TRIGGER tr1
              AFTER INSERT ON t1 FOR EACH ROW
               FETCH GROUP NEXT ROW;
            {code}

            h3. Events
            {code:sql}
            CREATE OR REPLACE EVENT ev1
              ON SCHEDULE EVERY 1 HOUR
              STARTS CURRENT_TIMESTAMP + INTERVAL 1 MONTH
              ENDS CURRENT_TIMESTAMP + INTERVAL 1 MONTH + INTERVAL 1 WEEK
            DO FETCH GROUP NEXT ROW;
            {code}
            bar Alexander Barkov made changes -
            Description The {{FETCH GROUP NEXT ROW}} statement is accepted in various unexpected contexts.

            h3. Procedures
            {code:sql}
            DELIMITER $$
            CREATE OR REPLACE PROCEDURE p1()
            BEGIN
              FETCH GROUP NEXT ROW;
            END;
            $$
            DELIMITER ;
            CALL p1;
            {code}
            It silently compiles and executes the procedure. The {{FETCH GROUP NEXT ROW}} is silently ignored.
            It should probably return an error at compile time, like inside a non-aggregate FUNCTION.

            h3. Anonymous blocks
            The same problem is repeatable with anonymous blocks:
            {code:sql}
            DELIMITER $$
            BEGIN NOT ATOMIC
              FETCH GROUP NEXT ROW;
            END;
            $$
            DELIMITER ;
            {code}

            h3. Non-aggregate functions with DEFINER
            If I add the {{DEFINER}} clause into a non-aggregate function, {{FETCH GROUP NEXT ROW}} is silently accepted:
            {code:sql}
            DELIMITER $$
            CREATE OR REPLACE DEFINER=root@localhost FUNCTION f1() RETURNS INT
            BEGIN
              FETCH GROUP NEXT ROW;
              RETURN 0;
            END;
            $$
            {code}

            h3. Triggers
            {code:sql}
            CREATE OR REPLACE TABLE t1 (a INT);
            CREATE OR REPLACE TRIGGER tr1
              AFTER INSERT ON t1 FOR EACH ROW
               FETCH GROUP NEXT ROW;
            {code}

            h3. Events
            {code:sql}
            CREATE OR REPLACE EVENT ev1
              ON SCHEDULE EVERY 1 HOUR
              STARTS CURRENT_TIMESTAMP + INTERVAL 1 MONTH
              ENDS CURRENT_TIMESTAMP + INTERVAL 1 MONTH + INTERVAL 1 WEEK
            DO FETCH GROUP NEXT ROW;
            {code}
            		The {{FETCH GROUP NEXT ROW}} statement is accepted in various unexpected contexts.

            h3. Procedures
            {code:sql}
            DELIMITER $$
            CREATE OR REPLACE PROCEDURE p1()
            BEGIN
              FETCH GROUP NEXT ROW;
            END;
            $$
            DELIMITER ;
            CALL p1;
            {code}
            It silently compiles and executes the procedure. The {{FETCH GROUP NEXT ROW}} is silently ignored.
            It should probably return an error at compile time, like inside a non-aggregate FUNCTION.

            h3. Anonymous blocks
            The same problem is repeatable with anonymous blocks:
            {code:sql}
            DELIMITER $$
            BEGIN NOT ATOMIC
              FETCH GROUP NEXT ROW;
            END;
            $$
            DELIMITER ;
            {code}

            h3. Non-aggregate functions with DEFINER
            If I add the {{DEFINER}} clause into a non-aggregate function, {{FETCH GROUP NEXT ROW}} is silently accepted:
            {code:sql}
            DELIMITER $$
            CREATE OR REPLACE DEFINER=root@localhost FUNCTION f1() RETURNS INT
            BEGIN
              FETCH GROUP NEXT ROW;
              RETURN 0;
            END;
            $$
            {code}

            h3. Triggers
            {code:sql}
            CREATE OR REPLACE TABLE t1 (a INT);
            CREATE OR REPLACE TRIGGER tr1
              AFTER INSERT ON t1 FOR EACH ROW
               FETCH GROUP NEXT ROW;
            {code}

            h3. Events
            {code:sql}
            CREATE OR REPLACE EVENT ev1
              ON SCHEDULE EVERY 1 HOUR
              STARTS CURRENT_TIMESTAMP + INTERVAL 1 MONTH
              ENDS CURRENT_TIMESTAMP + INTERVAL 1 MONTH + INTERVAL 1 WEEK
            DO FETCH GROUP NEXT ROW;
            {code}

            h3. Package body (10.4.4 only)
            {code:sql}
            SET sql_mode=ORACLE;
            DELIMITER $$
            CREATE OR REPLACE PACKAGE pkg1 AS
              PROCEDURE p1;
            END;
            CREATE OR REPLACE PACKAGE BODY pkg1 AS
              PROCEDURE p1 AS
              BEGIN
                FETCH GROUP NEXT ROW;
              END;
            END;
            $$
            {code}
            bar Alexander Barkov made changes -
            Description The {{FETCH GROUP NEXT ROW}} statement is accepted in various unexpected contexts.

            h3. Procedures
            {code:sql}
            DELIMITER $$
            CREATE OR REPLACE PROCEDURE p1()
            BEGIN
              FETCH GROUP NEXT ROW;
            END;
            $$
            DELIMITER ;
            CALL p1;
            {code}
            It silently compiles and executes the procedure. The {{FETCH GROUP NEXT ROW}} is silently ignored.
            It should probably return an error at compile time, like inside a non-aggregate FUNCTION.

            h3. Anonymous blocks
            The same problem is repeatable with anonymous blocks:
            {code:sql}
            DELIMITER $$
            BEGIN NOT ATOMIC
              FETCH GROUP NEXT ROW;
            END;
            $$
            DELIMITER ;
            {code}

            h3. Non-aggregate functions with DEFINER
            If I add the {{DEFINER}} clause into a non-aggregate function, {{FETCH GROUP NEXT ROW}} is silently accepted:
            {code:sql}
            DELIMITER $$
            CREATE OR REPLACE DEFINER=root@localhost FUNCTION f1() RETURNS INT
            BEGIN
              FETCH GROUP NEXT ROW;
              RETURN 0;
            END;
            $$
            {code}

            h3. Triggers
            {code:sql}
            CREATE OR REPLACE TABLE t1 (a INT);
            CREATE OR REPLACE TRIGGER tr1
              AFTER INSERT ON t1 FOR EACH ROW
               FETCH GROUP NEXT ROW;
            {code}

            h3. Events
            {code:sql}
            CREATE OR REPLACE EVENT ev1
              ON SCHEDULE EVERY 1 HOUR
              STARTS CURRENT_TIMESTAMP + INTERVAL 1 MONTH
              ENDS CURRENT_TIMESTAMP + INTERVAL 1 MONTH + INTERVAL 1 WEEK
            DO FETCH GROUP NEXT ROW;
            {code}

            h3. Package body (10.4.4 only)
            {code:sql}
            SET sql_mode=ORACLE;
            DELIMITER $$
            CREATE OR REPLACE PACKAGE pkg1 AS
              PROCEDURE p1;
            END;
            CREATE OR REPLACE PACKAGE BODY pkg1 AS
              PROCEDURE p1 AS
              BEGIN
                FETCH GROUP NEXT ROW;
              END;
            END;
            $$
            {code}
            		The {{FETCH GROUP NEXT ROW}} statement is accepted in various unexpected contexts.

            h3. Procedures
            {code:sql}
            DELIMITER $$
            CREATE OR REPLACE PROCEDURE p1()
            BEGIN
              FETCH GROUP NEXT ROW;
            END;
            $$
            DELIMITER ;
            CALL p1;
            {code}
            It silently compiles and executes the procedure. The {{FETCH GROUP NEXT ROW}} is silently ignored.
            It should probably return an error at compile time, like inside a non-aggregate FUNCTION.

            h3. Anonymous blocks
            The same problem is repeatable with anonymous blocks:
            {code:sql}
            DELIMITER $$
            BEGIN NOT ATOMIC
              FETCH GROUP NEXT ROW;
            END;
            $$
            DELIMITER ;
            {code}

            h3. Non-aggregate functions with DEFINER
            If I add the {{DEFINER}} clause into a non-aggregate function, {{FETCH GROUP NEXT ROW}} is silently accepted:
            {code:sql}
            DELIMITER $$
            CREATE OR REPLACE DEFINER=root@localhost FUNCTION f1() RETURNS INT
            BEGIN
              FETCH GROUP NEXT ROW;
              RETURN 0;
            END;
            $$
            {code}

            h3. Triggers
            {code:sql}
            CREATE OR REPLACE TABLE t1 (a INT);
            CREATE OR REPLACE TRIGGER tr1
              AFTER INSERT ON t1 FOR EACH ROW
               FETCH GROUP NEXT ROW;
            {code}

            h3. Events
            {code:sql}
            CREATE OR REPLACE EVENT ev1
              ON SCHEDULE EVERY 1 HOUR
              STARTS CURRENT_TIMESTAMP + INTERVAL 1 MONTH
              ENDS CURRENT_TIMESTAMP + INTERVAL 1 MONTH + INTERVAL 1 WEEK
            DO FETCH GROUP NEXT ROW;
            {code}

            h3. Package body (10.4.4 only)
            {code:sql}
            SET sql_mode=ORACLE;
            DELIMITER $$
            CREATE OR REPLACE PACKAGE pkg1 AS
              PROCEDURE p1;
            END;
            CREATE OR REPLACE PACKAGE BODY pkg1 AS
              PROCEDURE p1 AS
              BEGIN
                FETCH GROUP NEXT ROW;
              END;
            END;
            $$
            DELIMITER ;
            {code}
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            Description The {{FETCH GROUP NEXT ROW}} statement is accepted in various unexpected contexts.

            h3. Procedures
            {code:sql}
            DELIMITER $$
            CREATE OR REPLACE PROCEDURE p1()
            BEGIN
              FETCH GROUP NEXT ROW;
            END;
            $$
            DELIMITER ;
            CALL p1;
            {code}
            It silently compiles and executes the procedure. The {{FETCH GROUP NEXT ROW}} is silently ignored.
            It should probably return an error at compile time, like inside a non-aggregate FUNCTION.

            h3. Anonymous blocks
            The same problem is repeatable with anonymous blocks:
            {code:sql}
            DELIMITER $$
            BEGIN NOT ATOMIC
              FETCH GROUP NEXT ROW;
            END;
            $$
            DELIMITER ;
            {code}

            h3. Non-aggregate functions with DEFINER
            If I add the {{DEFINER}} clause into a non-aggregate function, {{FETCH GROUP NEXT ROW}} is silently accepted:
            {code:sql}
            DELIMITER $$
            CREATE OR REPLACE DEFINER=root@localhost FUNCTION f1() RETURNS INT
            BEGIN
              FETCH GROUP NEXT ROW;
              RETURN 0;
            END;
            $$
            {code}

            h3. Triggers
            {code:sql}
            CREATE OR REPLACE TABLE t1 (a INT);
            CREATE OR REPLACE TRIGGER tr1
              AFTER INSERT ON t1 FOR EACH ROW
               FETCH GROUP NEXT ROW;
            {code}

            h3. Events
            {code:sql}
            CREATE OR REPLACE EVENT ev1
              ON SCHEDULE EVERY 1 HOUR
              STARTS CURRENT_TIMESTAMP + INTERVAL 1 MONTH
              ENDS CURRENT_TIMESTAMP + INTERVAL 1 MONTH + INTERVAL 1 WEEK
            DO FETCH GROUP NEXT ROW;
            {code}

            h3. Package body (10.4.4 only)
            {code:sql}
            SET sql_mode=ORACLE;
            DELIMITER $$
            CREATE OR REPLACE PACKAGE pkg1 AS
              PROCEDURE p1;
            END;
            CREATE OR REPLACE PACKAGE BODY pkg1 AS
              PROCEDURE p1 AS
              BEGIN
                FETCH GROUP NEXT ROW;
              END;
            END;
            $$
            DELIMITER ;
            {code}
            		The {{FETCH GROUP NEXT ROW}} statement is accepted in various unexpected contexts.

            h3. Procedures
            {code:sql}
            DELIMITER $$
            CREATE OR REPLACE PROCEDURE p1()
            BEGIN
              FETCH GROUP NEXT ROW;
            END;
            $$
            DELIMITER ;
            CALL p1;
            {code}
            It silently compiles and executes the procedure. The {{FETCH GROUP NEXT ROW}} is silently ignored.
            It should probably return an error at compile time, like inside a non-aggregate FUNCTION.

            h3. Anonymous blocks
            The same problem is repeatable with anonymous blocks:
            {code:sql}
            DELIMITER $$
            BEGIN NOT ATOMIC
              FETCH GROUP NEXT ROW;
            END;
            $$
            DELIMITER ;
            {code}

            h3. Non-aggregate functions with DEFINER
            If I add the {{DEFINER}} clause into a non-aggregate function, {{FETCH GROUP NEXT ROW}} is silently accepted:
            {code:sql}
            DELIMITER $$
            CREATE OR REPLACE DEFINER=root@localhost FUNCTION f1() RETURNS INT
            BEGIN
              FETCH GROUP NEXT ROW;
              RETURN 0;
            END;
            $$
            {code}

            h3. Triggers
            {code:sql}
            CREATE OR REPLACE TABLE t1 (a INT);
            CREATE OR REPLACE TRIGGER tr1
              AFTER INSERT ON t1 FOR EACH ROW
               FETCH GROUP NEXT ROW;
            {code}

            h3. Events
            {code:sql}
            CREATE OR REPLACE EVENT ev1
              ON SCHEDULE EVERY 1 HOUR
              STARTS CURRENT_TIMESTAMP + INTERVAL 1 MONTH
              ENDS CURRENT_TIMESTAMP + INTERVAL 1 MONTH + INTERVAL 1 WEEK
            DO FETCH GROUP NEXT ROW;
            {code}

            h3. Package body (10.4.4 only)
            {code:sql}
            SET sql_mode=ORACLE;
            DELIMITER $$
            CREATE OR REPLACE PACKAGE pkg1 AS
              PROCEDURE p1;
            END;
            CREATE OR REPLACE PACKAGE BODY pkg1 AS
              PROCEDURE p1 AS
              BEGIN
                NULL;
              END;
            BEGIN
              FETCH GROUP NEXT ROW;
            END;
            $$
            DELIMITER ;
            {code}
            bar Alexander Barkov made changes -
            issue.field.resolutiondate 2019-03-07 14:59:31.0 2019-03-07 14:59:31.894
            bar Alexander Barkov made changes -
            Fix Version/s 10.4.4 [ 23310 ]
            Fix Version/s 10.4 [ 22408 ]
            Assignee Alexander Barkov [ bar ]
            Resolution Fixed [ 1 ]
            Status Open [ 1 ] Closed [ 6 ]
            serg Sergei Golubchik made changes -
            Workflow MariaDB v3 [ 92957 ] MariaDB v4 [ 155849 ]

            People

              bar Alexander Barkov
              bar Alexander Barkov
              Votes:
              0 Vote for this issue
              Watchers:
              2 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.