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

Support engine-defined attributes per partition

Details

    Description

      Overview

      MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

      Syntax

      partition_definition:
      		 
          PARTITION partition_name
      		 
              [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
      		 
              [[STORAGE] ENGINE [=] engine_name]
      		 
              [engine_defined_options ] 
              ...
      		 
              [(subpartition_definition [, subpartition_definition] ...)]

      https://mariadb.com/kb/en/create-table/#partitions

      Example

      Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

      CREATE TABLE tbl_a (
      		 
          a INT,
      		 
          b VARCHAR(255),
      		 
          PRIMARY KEY(a)
      		 
      ) ENGINE=Spider PARTITION BY RANGE(a) (
      		 
          PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
      		 
          PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
      		 
      )

      Note that the example above doesn't work with the current server implementation.

      Description

      • If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
      • Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
      • One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
      • We do not support, at least in the present issue, engine-defined attributes per subpartitions.

      TODO

      • Modify the parser to accept per-partition attributes;
      • Keep per-partition attributes some in-memory data structure (class partition_element ?);
      • Pass per-partition attributes to ha_partition::create() as per-table attributes;
      • Persist per-partition attributes in FRM files;
      • Modify the SHOW function to handle per-partition attributes. (unnecessary)
      • Make it work with subpartitions
      • Add test cases (subpartitioning, alter table)
      • Fix CONNECT tests failures: https://buildbot.mariadb.org/#/builders/236/builds/3094
      • Refactor the entire patch.

      Attachments

        Issue Links

          causes

          Bug - A problem which impairs or prevents the functions of the product. MDEV-27604 Values of partition-level options are not validated

          • Major - Major loss of function.
          • Open

          Bug - A problem which impairs or prevents the functions of the product. MDEV-27605 ALTER .. ADD PARTITION uses wrong partition-level option values

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

          Bug - A problem which impairs or prevents the functions of the product. MDEV-33153 EXCHANGE PARTITION leads to discrepancy in per-partition engine-defined attributes

          • Major - Major loss of function.
          • Open
          duplicates

          Task - A task that needs to be done. MDEV-8503 CONNECT STORAGE ENGINE

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

          Task - A task that needs to be done. MDEV-20635 Engine specific partition options like table options

          • Major - Major loss of function.
          • Closed
          is part of

          New Feature - A new feature of the product, which has yet to be developed. MDEV-22168 Supporting multiple engines with table partitioning

          • Critical - Crashes, loss of data, severe memory leak.
          • Stalled
          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-6322 The PARTITION engine can return wrong query results

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

          Task - A task that needs to be done. MDEV-27106 Spider: specify connection to data node by engine-defined attributes

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

          New Feature - A new feature of the product, which has yet to be developed. MDEV-27545 migrate server attributes applicable to engines to the storage engine(s)

          • Major - Major loss of function.
          • Open

          Task - A task that needs to be done. MDEV-3936 Storage-engine private data area per physical table

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

          Bug - A problem which impairs or prevents the functions of the product. MDEV-5058 engine options cannot be set together with partitioning

          • Major - Major loss of function.
          • Closed

          Task - A task that needs to be done. MDEV-22162 Make partitions more flexible to use

          • Major - Major loss of function.
          • Open

          Bug - A problem which impairs or prevents the functions of the product. MDEV-27564 Clearly specify/indicate in the partitioning manual which per-partition options are available

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

          Bug - A problem which impairs or prevents the functions of the product. MDEV-33183 Per-partition engine-defined attributes don't work for OQGraph

          • Trivial - Cosmetic problem like misspelt words or misaligned text.
          • Open

          Activity

            Ascending order - Click to sort in descending order
            serg Sergei Golubchik created issue -
            serg Sergei Golubchik made changes -
            Field Original Value New Value
            serg Sergei Golubchik made changes -
            serg Sergei Golubchik made changes -
            Assignee Sergei Golubchik [ serg ]
            serg Sergei Golubchik made changes -
            Priority Major [ 3 ] Minor [ 4 ]
            serg Sergei Golubchik made changes -
            Assignee Sergei Golubchik [ serg ]
            serg Sergei Golubchik made changes -
            bertrandop Olivier Bertrand made changes -
            Priority Minor [ 4 ] Major [ 3 ]
            bertrandop Olivier Bertrand made changes -
            serg Sergei Golubchik made changes -
            Workflow defaullt [ 29644 ] MariaDB v2 [ 44317 ]
            serg Sergei Golubchik made changes -
            Fix Version/s 10.1 [ 16100 ]
            Fix Version/s 10.1.0 [ 12200 ]
            serg Sergei Golubchik made changes -
            ratzpo Rasmus Johansson (Inactive) made changes -
            Workflow MariaDB v2 [ 44317 ] MariaDB v3 [ 63625 ]
            serg Sergei Golubchik made changes -
            Fix Version/s 10.2 [ 14601 ]
            Fix Version/s 10.1 [ 16100 ]
            serg Sergei Golubchik made changes -
            serg Sergei Golubchik made changes -
            Fix Version/s 10.2 [ 14601 ]
            serg Sergei Golubchik made changes -
            monty Michael Widenius made changes -
            GeoffMontee Geoff Montee (Inactive) made changes -
            ralf.gebhardt Ralf Gebhardt made changes -
            Component/s Partitioning [ 10802 ]
            ralf.gebhardt Ralf Gebhardt made changes -
            Priority Major [ 3 ] Critical [ 2 ]
            ralf.gebhardt Ralf Gebhardt made changes -
            Fix Version/s 10.6 [ 24028 ]
            bar Alexander Barkov made changes -
            ralf.gebhardt Ralf Gebhardt made changes -
            GeoffMontee Geoff Montee (Inactive) made changes -
            GeoffMontee Geoff Montee (Inactive) made changes -
            serg Sergei Golubchik made changes -
            Priority Critical [ 2 ] Major [ 3 ]
            ralf.gebhardt Ralf Gebhardt made changes -
            Fix Version/s 10.6 [ 24028 ]
            ralf.gebhardt Ralf Gebhardt made changes -
            ralf.gebhardt Ralf Gebhardt made changes -
            ralf.gebhardt Ralf Gebhardt made changes -
            ralf.gebhardt Ralf Gebhardt made changes -
            serg Sergei Golubchik made changes -
            serg Sergei Golubchik made changes -
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Assignee Sergei Golubchik [ serg ] Nayuta Yanagisawa [ JIRAUSER47117 ]
            serg Sergei Golubchik made changes -
            Fix Version/s 10.8 [ 26121 ]
            serg Sergei Golubchik made changes -
            Priority Major [ 3 ] Critical [ 2 ]
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description Engine can specify attributes that apply to tables, to indexes, to fields. But per-table attributes cannot be specified per partition. This needs to be supported. MariaDB allows storage engines to define additional attributes per index, field, or table. However, per table attributes cannot be specified per partition. We should support per-partition attributes In order to allow for more flexible configuration. Also, this functionality is necessary for other important features (see the issue links below).

             https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description MariaDB allows storage engines to define additional attributes per index, field, or table. However, per table attributes cannot be specified per partition. We should support per-partition attributes In order to allow for more flexible configuration. Also, this functionality is necessary for other important features (see the issue links below).

             https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/             		MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Summary engine attributes per partition Support engine attributes per partition
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Summary Support engine attributes per partition Support engine-defined attributes per partition
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/ MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            {code:sql}
            CREATE TABLE tbl_a (
              a INT,
              b VARCHAR(255),
              PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
              PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" table "ta_r2"',
              PARTITION pt3 VALUES LESS THAN MAXVALUE COMMENT='srv "s_2_1", table "ta_r4"'
            )
            {code}
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            {code:sql}
            CREATE TABLE tbl_a (
              a INT,
              b VARCHAR(255),
              PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
              PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" table "ta_r2"',
              PARTITION pt3 VALUES LESS THAN MAXVALUE COMMENT='srv "s_2_1", table "ta_r4"'
            )
            {code}             		MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r2",
                PARTITION pt3 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r4"'
            )
            {code}

            Note that the example above doesn't work with the current server implementation.
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r2",
                PARTITION pt3 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r4"'
            )
            {code}

            Note that the example above doesn't work with the current server implementation.             		h3. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h3. Details

            * It would be possible to specify the same attribute at table-level and partition-level. In such a case, the per-partition attribute would take precedence. So, we could consider per-table attributes as default values.
            *

            h3. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r2",
                PARTITION pt3 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r4"'
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h3. TODO

            * Modify the parser to accept per-partition attributes
            * Keep per-partition attributes in the handlerton struct
            * Pass per-partition attributes to ha_partition::create()
            * Persist per-partition attributes in FRM files
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h3. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h3. Details

            * It would be possible to specify the same attribute at table-level and partition-level. In such a case, the per-partition attribute would take precedence. So, we could consider per-table attributes as default values.
            *

            h3. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r2",
                PARTITION pt3 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r4"'
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h3. TODO

            * Modify the parser to accept per-partition attributes
            * Keep per-partition attributes in the handlerton struct
            * Pass per-partition attributes to ha_partition::create()
            * Persist per-partition attributes in FRM files
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Details

            * It is possible to specify the same attribute at table-level and partition-level. In such a case, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * ...

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r2",
                PARTITION pt3 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r4"'
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. TODO

            * Modify the parser to accept per-partition attributes
            * Keep per-partition attributes in the handlerton struct
            * Pass per-partition attributes to ha_partition::create()
            * Persist per-partition attributes in FRM files
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Details

            * It is possible to specify the same attribute at table-level and partition-level. In such a case, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * ...

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r2",
                PARTITION pt3 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r4"'
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. TODO

            * Modify the parser to accept per-partition attributes
            * Keep per-partition attributes in the handlerton struct
            * Pass per-partition attributes to ha_partition::create()
            * Persist per-partition attributes in FRM files
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Details

            * It is possible to specify the same attribute at table-level and partition-level. In such a case, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * ...

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"'
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. TODO

            * Modify the parser to accept per-partition attributes
            * Keep per-partition attributes in the handlerton struct
            * Pass per-partition attributes to ha_partition::create()
            * Persist per-partition attributes in FRM files
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Details

            * It is possible to specify the same attribute at table-level and partition-level. In such a case, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * ...

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"'
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. TODO

            * Modify the parser to accept per-partition attributes
            * Keep per-partition attributes in the handlerton struct
            * Pass per-partition attributes to ha_partition::create()
            * Persist per-partition attributes in FRM files
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Details

            * It is possible to specify the same attribute at table-level and partition-level. In such a case, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * ...

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"'
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. TODO

            * Modify the parser to accept per-partition attributes
            * Keep per-partition attributes in the handlerton struct
            * Pass per-partition attributes to ha_partition::create()
            * Persist per-partition attributes in FRM files
            * Modify the SHOW function to per-partition attributes
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Details

            * It is possible to specify the same attribute at table-level and partition-level. In such a case, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * ...

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"'
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. TODO

            * Modify the parser to accept per-partition attributes
            * Keep per-partition attributes in the handlerton struct
            * Pass per-partition attributes to ha_partition::create()
            * Persist per-partition attributes in FRM files
            * Modify the SHOW function to per-partition attributes
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Details

            * It is possible to specify the same attribute at table-level and partition-level. In such a case, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * ...

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"'
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. TODO

            * Modify the parser to accept per-partition attributes
            * Keep per-partition attributes in the handlerton struct
            * Pass per-partition attributes to ha_partition::create() as per-table attributes
            * Persist per-partition attributes in FRM files
            * Modify the SHOW function to per-partition attributes
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Details

            * It is possible to specify the same attribute at table-level and partition-level. In such a case, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * ...

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"'
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. TODO

            * Modify the parser to accept per-partition attributes
            * Keep per-partition attributes in the handlerton struct
            * Pass per-partition attributes to ha_partition::create() as per-table attributes
            * Persist per-partition attributes in FRM files
            * Modify the SHOW function to per-partition attributes
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Details

            * It is possible to specify the same attribute at table-level and partition-level. In such a case, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * ...

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"'
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. TODO

            * Modify the parser to accept per-partition attributes
            * Keep per-partition attributes in the handlerton struct
            * Pass per-partition attributes to ha_partition::create() as per-table attributes
            * Persist per-partition attributes in FRM files
            * Modify the SHOW function to handle per-partition attributes
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Details

            * It is possible to specify the same attribute at table-level and partition-level. In such a case, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * ...

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"'
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. TODO

            * Modify the parser to accept per-partition attributes
            * Keep per-partition attributes in the handlerton struct
            * Pass per-partition attributes to ha_partition::create() as per-table attributes
            * Persist per-partition attributes in FRM files
            * Modify the SHOW function to handle per-partition attributes
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Details

            * It is possible to specify the same attribute at table-level and partition-level. In such a case, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * ...

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. TODO

            * Modify the parser to accept per-partition attributes
            * Keep per-partition attributes in the handlerton struct
            * Pass per-partition attributes to ha_partition::create() as per-table attributes
            * Persist per-partition attributes in FRM files
            * Modify the SHOW function to handle per-partition attributes
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Details

            * It is possible to specify the same attribute at table-level and partition-level. In such a case, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * ...

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. TODO

            * Modify the parser to accept per-partition attributes
            * Keep per-partition attributes in the handlerton struct
            * Pass per-partition attributes to ha_partition::create() as per-table attributes
            * Persist per-partition attributes in FRM files
            * Modify the SHOW function to handle per-partition attributes
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Details

            * It is possible to specify the same attribute at table-level and partition-level. In such a case, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * ...

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. TODO

            * Modify the parser to accept per-partition attributes
            * Keep per-partition attributes some in-memory data structure (which one?).
            * Pass per-partition attributes to ha_partition::create() as per-table attributes
            * Persist per-partition attributes in FRM files
            * Modify the SHOW function to handle per-partition attributes
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Details

            * It is possible to specify the same attribute at table-level and partition-level. In such a case, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * ...

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. TODO

            * Modify the parser to accept per-partition attributes
            * Keep per-partition attributes some in-memory data structure (which one?).
            * Pass per-partition attributes to ha_partition::create() as per-table attributes
            * Persist per-partition attributes in FRM files
            * Modify the SHOW function to handle per-partition attributes
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Details

            * It is possible to specify the same attribute at table-level and partition-level. In such a case, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * ...

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. TODO

            * Modify the parser to accept per-partition attributes
            * Keep per-partition attributes some in-memory data structure (TABLE_SHARE?).
            * Pass per-partition attributes to ha_partition::create() as per-table attributes
            * Persist per-partition attributes in FRM files
            * Modify the SHOW function to handle per-partition attributes
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Details

            * It is possible to specify the same attribute at table-level and partition-level. In such a case, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * ...

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. TODO

            * Modify the parser to accept per-partition attributes
            * Keep per-partition attributes some in-memory data structure (TABLE_SHARE?).
            * Pass per-partition attributes to ha_partition::create() as per-table attributes
            * Persist per-partition attributes in FRM files
            * Modify the SHOW function to handle per-partition attributes
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Details

            * It is possible to specify the same attribute at table-level and partition-level. In such a case, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * ...

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. TODO

            * Modify the parser to accept per-partition attributes;
            * Keep per-partition attributes some in-memory data structure (TABLE_SHARE?);
            * Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes here. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            * Persist per-partition attributes in FRM files;
            * Modify the SHOW function to handle per-partition attributes.
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Details

            * It is possible to specify the same attribute at table-level and partition-level. In such a case, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * ...

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. TODO

            * Modify the parser to accept per-partition attributes;
            * Keep per-partition attributes some in-memory data structure (TABLE_SHARE?);
            * Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes here. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            * Persist per-partition attributes in FRM files;
            * Modify the SHOW function to handle per-partition attributes.
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Details

            * It is possible to specify the same attribute at table-level and partition-level. In such a case, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * ...

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. TODO

            * Modify the parser to accept per-partition attributes;
            * Keep per-partition attributes some in-memory data structure (TABLE_SHARE?);
            * Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            * Persist per-partition attributes in FRM files;
            * Modify the SHOW function to handle per-partition attributes.
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Details

            * It is possible to specify the same attribute at table-level and partition-level. In such a case, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * ...

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. TODO

            * Modify the parser to accept per-partition attributes;
            * Keep per-partition attributes some in-memory data structure (TABLE_SHARE?);
            * Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            * Persist per-partition attributes in FRM files;
            * Modify the SHOW function to handle per-partition attributes.
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * It is possible to specify the same attribute at table-level and partition-level. In such a case, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * ...

            h2. TODO

            * Modify the parser to accept per-partition attributes;
            * Keep per-partition attributes some in-memory data structure (TABLE_SHARE?);
            * Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            * Persist per-partition attributes in FRM files;
            * Modify the SHOW function to handle per-partition attributes.
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * It is possible to specify the same attribute at table-level and partition-level. In such a case, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * ...

            h2. TODO

            * Modify the parser to accept per-partition attributes;
            * Keep per-partition attributes some in-memory data structure (TABLE_SHARE?);
            * Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            * Persist per-partition attributes in FRM files;
            * Modify the SHOW function to handle per-partition attributes.
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * It is possible to specify the same attribute at table-level and partition-level. In such a case, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * If a table option is specified, it must be supported by all the storage engines that compose the partitioned table.

            h2. TODO

            * Modify the parser to accept per-partition attributes;
            * Keep per-partition attributes some in-memory data structure (TABLE_SHARE?);
            * Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            * Persist per-partition attributes in FRM files;
            * Modify the SHOW function to handle per-partition attributes.
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * It is possible to specify the same attribute at table-level and partition-level. In such a case, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * If a table option is specified, it must be supported by all the storage engines that compose the partitioned table.

            h2. TODO

            * Modify the parser to accept per-partition attributes;
            * Keep per-partition attributes some in-memory data structure (TABLE_SHARE?);
            * Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            * Persist per-partition attributes in FRM files;
            * Modify the SHOW function to handle per-partition attributes.
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * It is possible to specify the same attribute at table-level and partition-level. In such a case, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * If a table option is specified, it must be supported by all the storage engines that compose the partitioned table. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.

            h2. TODO

            * Modify the parser to accept per-partition attributes;
            * Keep per-partition attributes some in-memory data structure (TABLE_SHARE?);
            * Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            * Persist per-partition attributes in FRM files;
            * Modify the SHOW function to handle per-partition attributes.
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * It is possible to specify the same attribute at table-level and partition-level. In such a case, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * If a table option is specified, it must be supported by all the storage engines that compose the partitioned table. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.

            h2. TODO

            * Modify the parser to accept per-partition attributes;
            * Keep per-partition attributes some in-memory data structure (TABLE_SHARE?);
            * Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            * Persist per-partition attributes in FRM files;
            * Modify the SHOW function to handle per-partition attributes.
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * It is possible to specify the same attribute at table-level and partition-level. In such a case, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * It is possible to specify engine-defined attributes at table-level only when all the storage engines composing a partitioned table are the same. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.

            h2. TODO

            * Modify the parser to accept per-partition attributes;
            * Keep per-partition attributes some in-memory data structure (TABLE_SHARE?);
            * Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            * Persist per-partition attributes in FRM files;
            * Modify the SHOW function to handle per-partition attributes.
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * It is possible to specify the same attribute at table-level and partition-level. In such a case, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * It is possible to specify engine-defined attributes at table-level only when all the storage engines composing a partitioned table are the same. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.

            h2. TODO

            * Modify the parser to accept per-partition attributes;
            * Keep per-partition attributes some in-memory data structure (TABLE_SHARE?);
            * Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            * Persist per-partition attributes in FRM files;
            * Modify the SHOW function to handle per-partition attributes.
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * It is possible to specify the same attribute at table-level and partition-level. In such a case, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * Specifying engine-defined attributes at table-level is possible only when all the storage engines composing a partitioned table are the same. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.

            h2. TODO

            * Modify the parser to accept per-partition attributes;
            * Keep per-partition attributes some in-memory data structure (TABLE_SHARE?);
            * Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            * Persist per-partition attributes in FRM files;
            * Modify the SHOW function to handle per-partition attributes.
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * It is possible to specify the same attribute at table-level and partition-level. In such a case, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * Specifying engine-defined attributes at table-level is possible only when all the storage engines composing a partitioned table are the same. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.

            h2. TODO

            * Modify the parser to accept per-partition attributes;
            * Keep per-partition attributes some in-memory data structure (TABLE_SHARE?);
            * Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            * Persist per-partition attributes in FRM files;
            * Modify the SHOW function to handle per-partition attributes.
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying engine-defined attributes at table-level is only possible when all the storage engines composing a partitioned table are the same. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.

            h2. TODO

            * Modify the parser to accept per-partition attributes;
            * Keep per-partition attributes some in-memory data structure (TABLE_SHARE?);
            * Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            * Persist per-partition attributes in FRM files;
            * Modify the SHOW function to handle per-partition attributes.
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying engine-defined attributes at table-level is only possible when all the storage engines composing a partitioned table are the same. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.

            h2. TODO

            * Modify the parser to accept per-partition attributes;
            * Keep per-partition attributes some in-memory data structure (TABLE_SHARE?);
            * Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            * Persist per-partition attributes in FRM files;
            * Modify the SHOW function to handle per-partition attributes.
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying engine-defined attributes at table-level is only possible when all the storage engines composing a partitioned table are the same. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (x) Keep per-partition attributes some in-memory data structure (TABLE_SHARE?);
            * (x) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            * (x) Persist per-partition attributes in FRM files;
            * (x) Modify the SHOW function to handle per-partition attributes.
            serg Sergei Golubchik made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying engine-defined attributes at table-level is only possible when all the storage engines composing a partitioned table are the same. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (x) Keep per-partition attributes some in-memory data structure (TABLE_SHARE?);
            * (x) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            * (x) Persist per-partition attributes in FRM files;
            * (x) Modify the SHOW function to handle per-partition attributes.
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (x) Keep per-partition attributes some in-memory data structure (TABLE_SHARE?);
            * (x) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            * (x) Persist per-partition attributes in FRM files;
            * (x) Modify the SHOW function to handle per-partition attributes.
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (x) Keep per-partition attributes some in-memory data structure (TABLE_SHARE?);
            * (x) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            * (x) Persist per-partition attributes in FRM files;
            * (x) Modify the SHOW function to handle per-partition attributes.
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (x) Keep per-partition attributes some in-memory data structure (TABLE_SHARE?);
            * (x) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            * (x) Persist per-partition attributes in FRM files;
            * (x) Modify the SHOW function to handle per-partition attributes.
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (x) Keep per-partition attributes some in-memory data structure (TABLE_SHARE?);
            * (x) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            * (x) Persist per-partition attributes in FRM files;
            * (x) Modify the SHOW function to handle per-partition attributes.
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (x) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (x) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            * (x) Persist per-partition attributes in FRM files;
            * (x) Modify the SHOW function to handle per-partition attributes.
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (x) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (x) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            * (x) Persist per-partition attributes in FRM files;
            * (x) Modify the SHOW function to handle per-partition attributes.
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (x) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (x) Persist per-partition attributes in FRM files;
            * (x) Modify the SHOW function to handle per-partition attributes.
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (x) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (x) Persist per-partition attributes in FRM files;
            * (x) Modify the SHOW function to handle per-partition attributes.
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (/) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (x) Persist per-partition attributes in FRM files;
            * (x) Modify the SHOW function to handle per-partition attributes.
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (/) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (x) Persist per-partition attributes in FRM files;
            * (x) Modify the SHOW function to handle per-partition attributes.
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (x) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (x) Persist per-partition attributes in FRM files;
            * (x) Modify the SHOW function to handle per-partition attributes.
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (x) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (x) Persist per-partition attributes in FRM files;
            * (x) Modify the SHOW function to handle per-partition attributes.
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (x) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (/) Persist per-partition attributes in FRM files;
            * (x) Modify the SHOW function to handle per-partition attributes.
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (x) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (/) Persist per-partition attributes in FRM files;
            * (x) Modify the SHOW function to handle per-partition attributes.
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (x) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (/) Persist per-partition attributes in FRM files;
            * (/) -Modify the SHOW function to handle per-partition attributes.- (unnecessary)
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (x) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (/) Persist per-partition attributes in FRM files;
            * (/) -Modify the SHOW function to handle per-partition attributes.- (unnecessary)
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (/) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (/) Persist per-partition attributes in FRM files;
            * (/) -Modify the SHOW function to handle per-partition attributes.- (unnecessary)
            * (x) Refactor the entire patch.
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (/) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (/) Persist per-partition attributes in FRM files;
            * (/) -Modify the SHOW function to handle per-partition attributes.- (unnecessary)
            * (x) Refactor the entire patch.
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (/) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (/) Persist per-partition attributes in FRM files;
            * (/) -Modify the SHOW function to handle per-partition attributes.- (unnecessary)
            * (x) Fix CONNECT tests failures
            * (x) Refactor the entire patch.
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (/) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (/) Persist per-partition attributes in FRM files;
            * (/) -Modify the SHOW function to handle per-partition attributes.- (unnecessary)
            * (x) Fix CONNECT tests failures
            * (x) Refactor the entire patch.
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (/) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (/) Persist per-partition attributes in FRM files;
            * (/) -Modify the SHOW function to handle per-partition attributes.- (unnecessary)
            * (x) Fix CONNECT tests failures
            ** connect.bson
            ** connect.json
             ** connect.part_file
            * (x) Refactor the entire patch.
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (/) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (/) Persist per-partition attributes in FRM files;
            * (/) -Modify the SHOW function to handle per-partition attributes.- (unnecessary)
            * (x) Fix CONNECT tests failures
            ** connect.bson
            ** connect.json
             ** connect.part_file
            * (x) Refactor the entire patch.
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (/) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (/) Persist per-partition attributes in FRM files;
            * (/) -Modify the SHOW function to handle per-partition attributes.- (unnecessary)
            * (x) Add test cases (subpartitioning etc.)
            * (x) Fix CONNECT tests failures
            ** connect.bson
            ** connect.json
             ** connect.part_file
            * (x) Refactor the entire patch.
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (/) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (/) Persist per-partition attributes in FRM files;
            * (/) -Modify the SHOW function to handle per-partition attributes.- (unnecessary)
            * (x) Add test cases (subpartitioning etc.)
            * (x) Fix CONNECT tests failures
            ** connect.bson
            ** connect.json
             ** connect.part_file
            * (x) Refactor the entire patch.
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * -We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.-

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (/) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (/) Persist per-partition attributes in FRM files;
            * (/) -Modify the SHOW function to handle per-partition attributes.- (unnecessary)
            * (x) Add test cases (subpartitioning etc.)
            * (x) Fix CONNECT tests failures
            ** connect.bson
            ** connect.json
             ** connect.part_file
            * (x) Refactor the entire patch.
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * -We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.-

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (/) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (/) Persist per-partition attributes in FRM files;
            * (/) -Modify the SHOW function to handle per-partition attributes.- (unnecessary)
            * (x) Add test cases (subpartitioning etc.)
            * (x) Fix CONNECT tests failures
            ** connect.bson
            ** connect.json
             ** connect.part_file
            * (x) Refactor the entire patch.
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * -We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.-

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (/) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (/) Persist per-partition attributes in FRM files;
            * (/) -Modify the SHOW function to handle per-partition attributes.- (unnecessary)
            * (/) Make it work with subpartitions
            * (/) Add test cases (subpartitioning etc.)
            * (x) Fix CONNECT tests failures
            ** connect.bson
            ** connect.json
             ** connect.part_file
            * (x) Refactor the entire patch.
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * -We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.-

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (/) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (/) Persist per-partition attributes in FRM files;
            * (/) -Modify the SHOW function to handle per-partition attributes.- (unnecessary)
            * (/) Make it work with subpartitions
            * (/) Add test cases (subpartitioning etc.)
            * (x) Fix CONNECT tests failures
            ** connect.bson
            ** connect.json
             ** connect.part_file
            * (x) Refactor the entire patch.
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * -We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.-

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (/) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (/) Persist per-partition attributes in FRM files;
            * (/) -Modify the SHOW function to handle per-partition attributes.- (unnecessary)
            * (/) Make it work with subpartitions
            * (/) Add test cases (subpartitioning etc.)
            * (x) Fix CONNECT tests failures: https://buildbot.mariadb.org/#/builders/236/builds/3094
            * (x) Refactor the entire patch.
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * -We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.-

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (/) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (/) Persist per-partition attributes in FRM files;
            * (/) -Modify the SHOW function to handle per-partition attributes.- (unnecessary)
            * (/) Make it work with subpartitions
            * (/) Add test cases (subpartitioning etc.)
            * (x) Fix CONNECT tests failures: https://buildbot.mariadb.org/#/builders/236/builds/3094
            * (x) Refactor the entire patch.
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * -We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.-

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (/) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (/) Persist per-partition attributes in FRM files;
            * (/) -Modify the SHOW function to handle per-partition attributes.- (unnecessary)
            * (/) Make it work with subpartitions
            * (/) Add test cases (subpartitioning etc.)
            * (/) Fix CONNECT tests failures: https://buildbot.mariadb.org/#/builders/236/builds/3094
            * (x) Refactor the entire patch.
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * -We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.-

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (/) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (/) Persist per-partition attributes in FRM files;
            * (/) -Modify the SHOW function to handle per-partition attributes.- (unnecessary)
            * (/) Make it work with subpartitions
            * (/) Add test cases (subpartitioning etc.)
            * (/) Fix CONNECT tests failures: https://buildbot.mariadb.org/#/builders/236/builds/3094
            * (x) Refactor the entire patch.
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * -We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.-

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (/) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (/) Persist per-partition attributes in FRM files;
            * (/) -Modify the SHOW function to handle per-partition attributes.- (unnecessary)
            * (/) Make it work with subpartitions
            * (x) Add test cases (subpartitioning, alter table)
            * (/) Fix CONNECT tests failures: https://buildbot.mariadb.org/#/builders/236/builds/3094
            * (x) Refactor the entire patch.
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * -We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.-

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (/) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (/) Persist per-partition attributes in FRM files;
            * (/) -Modify the SHOW function to handle per-partition attributes.- (unnecessary)
            * (/) Make it work with subpartitions
            * (x) Add test cases (subpartitioning, alter table)
            * (/) Fix CONNECT tests failures: https://buildbot.mariadb.org/#/builders/236/builds/3094
            * (x) Refactor the entire patch.
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (/) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (/) Persist per-partition attributes in FRM files;
            * (/) -Modify the SHOW function to handle per-partition attributes.- (unnecessary)
            * (/) Make it work with subpartitions
            * (x) Add test cases (subpartitioning, alter table)
            * (/) Fix CONNECT tests failures: https://buildbot.mariadb.org/#/builders/236/builds/3094
            * (x) Refactor the entire patch.
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (/) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (/) Persist per-partition attributes in FRM files;
            * (/) -Modify the SHOW function to handle per-partition attributes.- (unnecessary)
            * (/) Make it work with subpartitions
            * (x) Add test cases (subpartitioning, alter table)
            * (/) Fix CONNECT tests failures: https://buildbot.mariadb.org/#/builders/236/builds/3094
            * (x) Refactor the entire patch.
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (/) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (/) Persist per-partition attributes in FRM files;
            * (/) -Modify the SHOW function to handle per-partition attributes.- (unnecessary)
            * (/) Make it work with subpartitions
            * (/) Add test cases (subpartitioning, alter table)
            * (/) Fix CONNECT tests failures: https://buildbot.mariadb.org/#/builders/236/builds/3094
            * (x) Refactor the entire patch.
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Assignee Nayuta Yanagisawa [ JIRAUSER47117 ] Alexey Botchkov [ holyfoot ]
            Status In Progress [ 3 ] In Review [ 10002 ]
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (/) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (/) Persist per-partition attributes in FRM files;
            * (/) -Modify the SHOW function to handle per-partition attributes.- (unnecessary)
            * (/) Make it work with subpartitions
            * (/) Add test cases (subpartitioning, alter table)
            * (/) Fix CONNECT tests failures: https://buildbot.mariadb.org/#/builders/236/builds/3094
            * (x) Refactor the entire patch.
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (/) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (/) Persist per-partition attributes in FRM files;
            * (/) -Modify the SHOW function to handle per-partition attributes.- (unnecessary)
            * (/) Make it work with subpartitions
            * (/) Add test cases (subpartitioning, alter table)
            * (/) Fix CONNECT tests failures: https://buildbot.mariadb.org/#/builders/236/builds/3094
            * (/) Refactor the entire patch.
            holyfoot Alexey Botchkov made changes -
            Assignee Alexey Botchkov [ holyfoot ] Nayuta Yanagisawa [ JIRAUSER47117 ]
            Status In Review [ 10002 ] Stalled [ 10000 ]
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Status Stalled [ 10000 ] In Progress [ 3 ]
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Assignee Nayuta Yanagisawa [ JIRAUSER47117 ] Alexey Botchkov [ holyfoot ]
            Status In Progress [ 3 ] In Review [ 10002 ]
            holyfoot Alexey Botchkov made changes -
            Assignee Alexey Botchkov [ holyfoot ] Nayuta Yanagisawa [ JIRAUSER47117 ]
            Status In Review [ 10002 ] Stalled [ 10000 ]
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Description h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (/) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (/) Persist per-partition attributes in FRM files;
            * (/) -Modify the SHOW function to handle per-partition attributes.- (unnecessary)
            * (/) Make it work with subpartitions
            * (/) Add test cases (subpartitioning, alter table)
            * (/) Fix CONNECT tests failures: https://buildbot.mariadb.org/#/builders/236/builds/3094
            * (/) Refactor the entire patch.
            		h2. Overview

            MariaDB allows storage engines to define additional attributes per index, field, or table. However, per-table attributes cannot be specified per partition. We should support per-partition attributes for more flexible configurations. Also, this functionality is necessary for other important features (see the issue links below). https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/

            h2. Syntax

            {noformat}
            partition_definition:
                PARTITION partition_name
                    [VALUES {LESS THAN {(expr) | MAXVALUE} | IN (value_list)}]
                    [[STORAGE] ENGINE [=] engine_name]
                    [engine_defined_options ]
                    ...
                    [(subpartition_definition [, subpartition_definition] ...)]
            {noformat}

            https://mariadb.com/kb/en/create-table/#partitions

            h2. Example

            Here is a possible use case of the per-partition attributes support. By the use of per-partition attributes, the Spider storage engine (and other federated engines) can provide users with a cleaner way to specify where to connect.

            {code:sql}
            CREATE TABLE tbl_a (
                a INT,
                b VARCHAR(255),
                PRIMARY KEY(a)
            ) ENGINE=Spider PARTITION BY RANGE(a) (
                PARTITION pt1 VALUES LESS THAN (100) REMOTE_SERVER="s_2_1" REMOTE_TABLE="ta_r1",
                PARTITION pt2 VALUES LESS THAN MAXVALUE REMOTE_SERVER="s_2_1", REMOTE_TABLE="ta_r2"
            )
            {code}

            Note that the example above doesn't work with the current server implementation.

            h2. Description

            * If an engine-defined attribute is specified at table-level, it applies to all the partitions in the table (backward compatible behavior).
            * Specifying an engine-defined attribute at table-level is only possible when all the storage engines composing a partitioned table support this attribute. Currently, it is not possible to use multiple storage engines to create a partitioned table, but this will be possible in MDEV-22168.
            * One can use both per-table attributes and per-partition attributes for a single table. If the same attribute is specified both at table-level and partition-level, the per-partition attribute takes precedence. So, we can consider per-table attributes as default values.
            * We do not support, at least in the present issue, engine-defined attributes per _subpartitions_.

            h2. TODO

            * (/) Modify the parser to accept per-partition attributes;
            * (/) Keep per-partition attributes some in-memory data structure (class partition_element ?);
            * (/) Pass per-partition attributes to ha_partition::create() as _per-table attributes_;
            ** This is to keep the handler mostly oblivious whether it's a partition or a table.
            ** The partition storage engine has a hook point to modify TABLE_SHARE. We can also set up per-table attributes there. https://github.com/MariaDB/server/blob/mariadb-10.7.1/sql/ha_partition.cc#L2722
            ** Per-table attributes and per-partition attributes should be merged before table creation.
            * (/) Persist per-partition attributes in FRM files;
            * (/) -Modify the SHOW function to handle per-partition attributes.- (unnecessary)
            * (/) -Make it work with subpartitions-
            * (/) Add test cases (subpartitioning, alter table)
            * (/) Fix CONNECT tests failures: https://buildbot.mariadb.org/#/builders/236/builds/3094
            * (/) Refactor the entire patch.
            serg Sergei Golubchik made changes -
            Workflow MariaDB v3 [ 63625 ] MariaDB v4 [ 131628 ]
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            serg Sergei Golubchik made changes -
            Status Stalled [ 10000 ] In Testing [ 10301 ]
            serg Sergei Golubchik made changes -
            Assignee Nayuta Yanagisawa [ JIRAUSER47117 ]
            serg Sergei Golubchik made changes -
            Assignee Roel Van de Paar [ roel ]
            Roel Roel Van de Paar made changes -
            Roel Roel Van de Paar made changes -
            Roel Roel Van de Paar made changes -
            Assignee Roel Van de Paar [ roel ] Sergei Golubchik [ serg ]
            Status In Testing [ 10301 ] Stalled [ 10000 ]
            serg Sergei Golubchik made changes -
            Assignee Sergei Golubchik [ serg ] Nayuta Yanagisawa [ JIRAUSER47117 ]
            serg Sergei Golubchik made changes -
            Priority Critical [ 2 ] Blocker [ 1 ]
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) made changes -
            Fix Version/s 10.8.1 [ 26815 ]
            Fix Version/s 10.8 [ 26121 ]
            Resolution Done [ 10200 ]
            Status Stalled [ 10000 ] Closed [ 6 ]
            elenst Elena Stepanova made changes -
            elenst Elena Stepanova made changes -
            elenst Elena Stepanova made changes -
            elenst Elena Stepanova made changes -

            People

              nayuta-yanagisawa Nayuta Yanagisawa (Inactive)
              serg Sergei Golubchik
              Votes:
              6 Vote for this issue
              Watchers:
              14 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.