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

Add system variable explicit_defaults_for_timestamp for compatibility with MySQL

Details

    • 10.1.6-2, 10.1.8-1, 10.1.8-2

    Description

      As the description of the main task MDEV-452 already mentions, MySQL implementation has the variable explicit_defaults_for_timestamp which modifies the behavior of auto-updated temporal columns. Since the planned release approaches and we don't have the variable yet, we either need to add it now, or decide to release without it, and add it in further versions. Either is okay as long as it's not completely forgotten.

      The definition of MySQL's implementation can be found here:
      http://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_explicit_defaults_for_timestamp

      What we should do in MariaDB:

      • Add this new variable and have it work as MySQL when enabled.
      • Have it disabled as default, to not cause incompatibilities with old applications
      • Always keep the variable around (not make it deprecated) as we don't want to have it default.
      • Add a MYSQL mode where, if enabled, this variable is set.

      TODO: check how replication of this variable works in MySQL.

      Attachments

        Issue Links

          blocks

          Task - A task that needs to be done. MDEV-8455 Make explicit_defaults_for_timestamp dynamic

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Open
          duplicates

          Task - A task that needs to be done. MDEV-5994 MySQL WL#6292 - Make TIMESTAMP columns nullable by default

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Closed
          is blocked by

          Bug - A problem which impairs or prevents the functions of the product. MDEV-7824 [Bug #68041] Zero date can be inserted in strict no-zero mode through a default value

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-7831 Bad warning for DATE_ADD(timestamp_column, INTERVAL 10 SECOND)

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-8441 Bad SHOW CREATE TABLE output for a table with a virtual column

          • Major - Major loss of function.
          • Closed
          is duplicated by

          Bug - A problem which impairs or prevents the functions of the product. MDEV-5836 MySQL WL#6292 - Make TIMESTAMP columns nullable by default

          • Major - Major loss of function.
          • Closed
          relates to

          Task - A task that needs to be done. MDEV-452 Add full support for auto-initialized/updated timestamp and datetime

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-28983 TIMESTAMP logic remains partly non-standard with explicit_defaults_for_timestamp

          • Major - Major loss of function.
          • Open
          links to

          Web Link Bug #68472

          Activity

            Ascending order - Click to sort in descending order
            View 4 older comments
            timour Timour Katchaounov (Inactive) added a comment -

            Monty's suggestion is to implement the flag without changes to replication,
            but instead move all dynamic decisions to the parser, so that the timestamp
            fields are created according to this flag. That is, the different behavior is
            recorded in the table definition, instead of checking every time at runtime.

            timour Timour Katchaounov (Inactive) added a comment - Monty's suggestion is to implement the flag without changes to replication, but instead move all dynamic decisions to the parser, so that the timestamp fields are created according to this flag. That is, the different behavior is recorded in the table definition, instead of checking every time at runtime.
            elenst Elena Stepanova added a comment -

            In case we ever decide to implement it, check the status of http://bugs.mysql.com/bug.php?id=68472 (just filed, I'm not sure whether it's going to be fixed or rejected as 'Not a bug').

            elenst Elena Stepanova added a comment - In case we ever decide to implement it, check the status of http://bugs.mysql.com/bug.php?id=68472 (just filed, I'm not sure whether it's going to be fixed or rejected as 'Not a bug').
            elenst Elena Stepanova added a comment -

            See MDEV-5836 for the upstream revision/commit message.

            elenst Elena Stepanova added a comment - See MDEV-5836 for the upstream revision/commit message.
            bar Alexander Barkov added a comment - - edited

            Monty suggested the following regarding replication of explicit_defaults_for_timestamp:

            ok, the easy way to do this would be:
            Change SELECT_DISTINCT from 1 to (1ULL << 39)
            Add - OPTION_explicit_defaults_for_timestamp as 1
            Add OPTION_explicit_defaults_for_timestamp to OPTIONS_WRITTEN_TO_BIN_LOG
            In Query_log_event::do_apply_event set explicit_defaults_for_timestamp if OPTION_explicit_defaults_for_timestamp is set
            That should help ensure:

            • If you replicate from mariadb to mariadb, the slave will follow the master
            • If you replicate from MySQL to MariaDB, you have to have the same setting for MySQL and MariaDB
              Not much we can do for the second case, but the first case is the important one

            Also, Monty suggests to make the variable dynamic in the future.

            bar Alexander Barkov added a comment - - edited Monty suggested the following regarding replication of explicit_defaults_for_timestamp: ok, the easy way to do this would be: Change SELECT_DISTINCT from 1 to (1ULL << 39) Add - OPTION_explicit_defaults_for_timestamp as 1 Add OPTION_explicit_defaults_for_timestamp to OPTIONS_WRITTEN_TO_BIN_LOG In Query_log_event::do_apply_event set explicit_defaults_for_timestamp if OPTION_explicit_defaults_for_timestamp is set That should help ensure: If you replicate from mariadb to mariadb, the slave will follow the master If you replicate from MySQL to MariaDB, you have to have the same setting for MySQL and MariaDB Not much we can do for the second case, but the first case is the important one Also, Monty suggests to make the variable dynamic in the future.
            elenst Elena Stepanova added a comment -

            Please note it is already deprecated in MySQL:
            http://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_explicit_defaults_for_timestamp

            explicit_defaults_for_timestamp is itself deprecated because its only purpose is to permit control over now-deprecated TIMESTAMP behaviors that will be removed in a future MySQL release. When that removal occurs, explicit_defaults_for_timestamp will have no purpose and will be removed as well.

            elenst Elena Stepanova added a comment - Please note it is already deprecated in MySQL: http://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_explicit_defaults_for_timestamp explicit_defaults_for_timestamp is itself deprecated because its only purpose is to permit control over now-deprecated TIMESTAMP behaviors that will be removed in a future MySQL release. When that removal occurs, explicit_defaults_for_timestamp will have no purpose and will be removed as well.

            People

              bar Alexander Barkov
              elenst Elena Stepanova
              Votes:
              1 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.