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

"default collation" ids for the protocol

Details

    • New Feature
    • Status: Closed (View Workflow)
    • Critical
    • Resolution: Fixed
    • N/A
    • Protocol
    • None

    Description

      Connection protocol only has one byte for selecting a collation. This is no longer enough. So connectors are forced to do SET NAMES on every connection.

      On the other hand, normally connectors don't care about a collation and only need to set a correct character set, and that most of the time is utf8.

      There are 41 unused values in the 0-255 range of collation ids.
      They could be used for "default collation" ids, like, for example, "220 = default collation of utf8mb4", etc.

      Then a connector will still be able to use one-byte in the protocol to set a character set of its choice and won't need SET NAMES.

      Attachments

        Issue Links

          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-33182 Server assertion fails when trying to test the connection with DBeaver

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

          Bug - A problem which impairs or prevents the functions of the product. MDEV-32975 Default charset doesn't work with PHP MySQLi extension

          • Blocker - Blocks development and/or testing work, production could not run.
          • Closed

          Activity

            Descending order - Click to sort in ascending order
            serg Sergei Golubchik added a comment -

            This turned out to be already the case, default collations of all character sets always have id < 256, so they can be set in the handshake and don't require SET NAMES

            serg Sergei Golubchik added a comment - This turned out to be already the case, default collations of all character sets always have id < 256, so they can be set in the handshake and don't require SET NAMES
            bar Alexander Barkov added a comment - - edited

            I don't think we need special "default collation" IDs.

            After MDEV-33182, it works as follows:

            • a. If the client sent a non-default collation ID, then the server uses this ID for @@collation_connection.
            • b. If the client sent a compiled default collation ID (like 33 == utf8mb3_general_ci), then the server user @@character_set_collations to resolve @@collation_connection.

            So the compiled default collation IDs already work as "default collation".

            However, the comment added by MDEV-33182 suggests:

                  Perhaps eventually we should change (b) also to resolve non-default
            		 
                  collations according to @@character_set_collations. Clients that used to
            		 
                  send a non-default collation ID in the handshake packet will have to set
            		 
                  @@character_set_collations instead.

            If we decide to go this way, we'll need something to allow the client to indicate
            if it wants its collation ID to be processed by @@character_set_collations, or to be used as is.

            Anyway, adding special collations IDs looks like over-engineering for me. I'd prefer some bit flag in the handshake header.

            bar Alexander Barkov added a comment - - edited I don't think we need special "default collation" IDs. After MDEV-33182 , it works as follows: a. If the client sent a non-default collation ID, then the server uses this ID for @@collation_connection. b. If the client sent a compiled default collation ID (like 33 == utf8mb3_general_ci), then the server user @@character_set_collations to resolve @@collation_connection. So the compiled default collation IDs already work as "default collation". However, the comment added by MDEV-33182 suggests: Perhaps eventually we should change (b) also to resolve non-default collations according to @@character_set_collations. Clients that used to send a non-default collation ID in the handshake packet will have to set @@character_set_collations instead. If we decide to go this way, we'll need something to allow the client to indicate if it wants its collation ID to be processed by @@character_set_collations, or to be used as is. Anyway, adding special collations IDs looks like over-engineering for me. I'd prefer some bit flag in the handshake header.
            serg Sergei Golubchik added a comment -

            see the this comment in MDEV-32975.

            I think that MDEV-32966 will solve MDEV-32975, but there's also another solution for MDEV-32975 which doesn't include MDEV-32966

            serg Sergei Golubchik added a comment - see the this comment in MDEV-32975 . I think that MDEV-32966 will solve MDEV-32975 , but there's also another solution for MDEV-32975 which doesn't include MDEV-32966

            People

              bar Alexander Barkov
              serg Sergei Golubchik
              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.