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

Change of behaviour of OR in IF-conditions 10.2 -> 10.3

Details

    • Bug
    • Status: Closed (View Workflow)
    • Critical
    • Resolution: Fixed
    • 10.3.11, 10.2(EOL), 10.3(EOL), 10.4(EOL)
    • 10.2.23
    • Optimizer
    • Windows 10, Windows Server 2008

    Description

      The behavior of the OR operator in the IF condition has changed from MariaDB 10.2 to 10.3.
      now I noticed that the following syntax doesn't work in SELECT statements anymore:

      SELECT * FROM tab t WHERE IF(@a = 1, t.a = 1 OR t.b = 1,1=1)
      

      Now I'd have to write:

      SELECT * FROM tab t WHERE (IF(@a = 1, t.a = 1, 1=1) OR IF(@a = 1, t.b = 1, 1=1))
      

      Is it a bug or a deliberate change? Is there a setting with which I can reactivate the previous behavior?

      Attachments

        Issue Links

          Activity

            FriedemannS Friedemann Schmidt added a comment - Is there a relation to https://jira.mariadb.org/browse/MDEV-18605 too ?
            alice Alice Sherepa added a comment -

            FriedemannS No, I guess not. MDEV-18605 is not repeatable on the latest 10.2

            alice Alice Sherepa added a comment - FriedemannS No, I guess not. MDEV-18605 is not repeatable on the latest 10.2

            This bug occurs because the condition that shouldn't be pushed is pushed into the derived table.
            This issue is similar with MDEV-16765.

            In this special case OR-condition inside the IF-function is defined as dependent only on fields
            of the derived table while it is not. It happens because Item_cond::excl_dep_on_table() is missing.

            When going through the IF-function virtual function excl_dep_on_table() reaches OR condition
            it defines it as Item_func element and tries to take its arguments. It tries to take them from 'args' array.
            Item_cond has empty 'args' array. All its elements are stored in the list 'list'.
            So 'args' array is empty and this function defines that this OR condition depends only on the fields of the derived table and it can be pushed.
            That causes a wrong result.

            To fix it Item_cond::excl_dep_on_table() needs to be added.

            shagalla Galina Shalygina (Inactive) added a comment - This bug occurs because the condition that shouldn't be pushed is pushed into the derived table. This issue is similar with MDEV-16765 . In this special case OR-condition inside the IF-function is defined as dependent only on fields of the derived table while it is not. It happens because Item_cond::excl_dep_on_table() is missing. When going through the IF-function virtual function excl_dep_on_table() reaches OR condition it defines it as Item_func element and tries to take its arguments. It tries to take them from 'args' array. Item_cond has empty 'args' array. All its elements are stored in the list 'list'. So 'args' array is empty and this function defines that this OR condition depends only on the fields of the derived table and it can be pushed. That causes a wrong result. To fix it Item_cond::excl_dep_on_table() needs to be added.
            igor Igor Babaev added a comment -

            Ok to push after a minor correction in the patch comment.

            igor Igor Babaev added a comment - Ok to push after a minor correction in the patch comment.

            Pushed in 10.2

            shagalla Galina Shalygina (Inactive) added a comment - Pushed in 10.2

            People

              shagalla Galina Shalygina (Inactive)
              FriedemannS Friedemann Schmidt
              Votes:
              0 Vote for this issue
              Watchers:
              6 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.