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

MySQL bug#11747847 - 34280: create table fails if NO_ZERO_DATE or NO_ZERO_IN_DATE SQL mode is set

        Details

        • Type: Bug
        • Status: Closed
        • Priority: Major
        • Resolution: Won't Fix
        • Affects Version/s: 10.0.9
        • Fix Version/s: 10.0.11
        • Component/s: None
        • Labels:
          None

          Description

          Test case for MySQL "bug#11747847 - 34280: create table fails if NO_ZERO_DATE or NO_ZERO_IN_DATE SQL mode is set" fails in 10.0.

          Test diff attached. Please try to apply test case as is unless it is applicable.

            Gliffy Diagrams

              Attachments

                Issue Links

                is part of

                Task - A task that needs to be done. MDEV-4784 merge test cases from 5.6

                • Minor - Minor loss of function, or other problem where easy workaround is present.
                • Stalled
                links to

                Web Link Bug #34280 CREATE TABLE fails if in NO_ZERO_DATE SQL mode

                  Activity

                  Hide
                  Permalink
                  serg Sergei Golubchik added a comment -

                  I'm not sure we need to fix it. Current behavior is consistent — everything that causes a truncation warning during INSERT is rejected as a default value on CREATE. Compare:

                  1. SET SQL_MODE=NO_ZERO_DATE; INSERT t1 (timestamp_column) VALUES (0);
                  2. SET SQL_MODE=NO_ZERO_DATE; CREATE TABLE t2 (a TIMESTAMP 0);
                  3. INSERT t3 (tinyint_column) VALUES (1000)
                  4. CREATE TABLE t4 (a TINYINT 1000);

                  Both 1 and 3 will issue a truncation warning. Both 2 and 4 will fail. This is consistent.
                  After Oracle's fix for MySQL bug #11747847 - 34280, the 2 won't fail. But 4 still will.
                  This is inconsistent.

                  I'd prefer to leave it as is, or to fix both 2 and 4 not to fail, a.k.a. use the same logic in INSERT and CREATE.

                  Show
                  serg Sergei Golubchik added a comment - I'm not sure we need to fix it. Current behavior is consistent — everything that causes a truncation warning during INSERT is rejected as a default value on CREATE. Compare: SET SQL_MODE=NO_ZERO_DATE; INSERT t1 (timestamp_column) VALUES (0); SET SQL_MODE=NO_ZERO_DATE; CREATE TABLE t2 (a TIMESTAMP 0); INSERT t3 (tinyint_column) VALUES (1000) CREATE TABLE t4 (a TINYINT 1000); Both 1 and 3 will issue a truncation warning. Both 2 and 4 will fail. This is consistent. After Oracle's fix for MySQL bug #11747847 - 34280, the 2 won't fail. But 4 still will. This is inconsistent. I'd prefer to leave it as is, or to fix both 2 and 4 not to fail, a.k.a. use the same logic in INSERT and CREATE.

                    People

                    • Assignee:
                      serg Sergei Golubchik
                      Reporter:
                      svoj Sergey Vojtovich
                    • Votes:
                      0 Vote for this issue
                      Watchers:
                      2 Start watching this issue

                      Dates

                      • Created:
                        Updated:
                        Resolved: