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 added a comment -

            There are more problems withe the PARTITION engine, for instances:

            If the original table has a CONNECTION string, it is lost when calling the partition tables

            Query pruning can loose existing data (MDEV-6322)

            These issues need to be handled.

            bertrandop Olivier Bertrand added a comment - There are more problems withe the PARTITION engine, for instances: If the original table has a CONNECTION string, it is lost when calling the partition tables Query pruning can loose existing data ( MDEV-6322 ) These issues need to be handled.
            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 -
            serg Sergei Golubchik added a comment -

            frm does not store attributes per partition and in memory data structures have only one list of attributes per table.

            serg Sergei Golubchik added a comment - frm does not store attributes per partition and in memory data structures have only one list of attributes per table.
            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 ]
            bertrandop Olivier Bertrand added a comment -

            Why only version 10.6?

            bertrandop Olivier Bertrand added a comment - Why only version 10.6?
            serg Sergei Golubchik added a comment -

            it's expected to be a pretty intrusive internal refactoring. If it'll turn out to be something smaller and safer we can backport it to earlier versions.

            serg Sergei Golubchik added a comment - it's expected to be a pretty intrusive internal refactoring. If it'll turn out to be something smaller and safer we can backport it to earlier versions.
            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) added a comment -

            ralf.gebhardt@mariadb.com and serg. In MariaDB, there seem to be two types of table options, one is engine-specific and the other is non-engine-specific. And, they seemed to be treated differently. For example, PAGE_COMPRESSED is an InnoDB specific option and STATS_AUTO_RECALC is a non-engine specific option (while STATS_AUTO_RECALC seems to be used only by InnoDB).

            Can I limit the scope of the issue to the engine-specific options? Of course, we may need to make similar enhancements to the non-engine-specific options, but I would like to make it by a separate task.

            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) added a comment - ralf.gebhardt@mariadb.com and serg . In MariaDB, there seem to be two types of table options, one is engine-specific and the other is non-engine-specific. And, they seemed to be treated differently. For example, PAGE_COMPRESSED is an InnoDB specific option and STATS_AUTO_RECALC is a non-engine specific option (while STATS_AUTO_RECALC seems to be used only by InnoDB). Can I limit the scope of the issue to the engine-specific options? Of course, we may need to make similar enhancements to the non-engine-specific options, but I would like to make it by a separate task.
            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
            serg Sergei Golubchik added a comment - - edited

            Yes, this is only about engine-defined attributes, those that are not hard-coded in the server, but declared by the engine using the dedicated API

            serg Sergei Golubchik added a comment - - edited Yes, this is only about engine-defined attributes, those that are not hard-coded in the server, but declared by the engine using the dedicated API
            maxmether Max Mether added a comment -

            Just note that we also want to implement MDEV-22168 and that whatever is done in this MDEV should of course support what will be done in that MDEV.

            maxmether Max Mether added a comment - Just note that we also want to implement MDEV-22168 and that whatever is done in this MDEV should of course support what will be done in that MDEV.
            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) added a comment -

            I understand. Thank you very much!

            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) added a comment - I understand. Thank you very much!
            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.
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) added a comment -

            serg, ralf.gebhardt@mariadb.com I wrote out some details of the per-partition attribute. Please comment if you have any concerns or if there is anything that needs to be fixed.

            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) added a comment - serg , ralf.gebhardt@mariadb.com I wrote out some details of the per-partition attribute. Please comment if you have any concerns or if there is anything that needs to be fixed.
            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) added a comment -

            holyfoot Please review: https://github.com/MariaDB/server/commit/473ece969dbba474d2aa146466e66238bb373d28

            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) added a comment - holyfoot Please review: https://github.com/MariaDB/server/commit/473ece969dbba474d2aa146466e66238bb373d28
            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.
            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) added a comment - - edited

            holyfoot I slightly updated my patch: https://github.com/MariaDB/server/commit/53fb89c94154ff8879af7a0c1dc8e41bb98164a3

            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) added a comment - - edited holyfoot I slightly updated my patch: https://github.com/MariaDB/server/commit/53fb89c94154ff8879af7a0c1dc8e41bb98164a3
            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) added a comment - - edited

            holyfoot Thank you for your review. I update my patch according to your comments. Please review the updated version: https://github.com/MariaDB/server/commit/88e445850b90db963704076b750bea0b26e555c8

            Summary of the changes:

            • Duplications in sql_yacc.yy are removed;
            • The patch is formated by clang-format-diff;
            • The call of link() is removed from the engine_option_value constructions;
            • The error handling for the new operator on engine_option_value is added;
            • Some functions are renamed for consistency;
            • opt_ prefix of some expressions in sql_yacc.yy are revoed for consistency.

            What has not yet been fixed:

            - ERROR 42000: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'ts1,
            		 
            + ERROR 42000: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '

            The diff above seems to be due to the extension of the syntax.

            An engine-defined option name can be an arbitrary identity and thus the parser is not able to determine that it is a syntax error until it reads a later token. The function parse_error() just print the last token parsed. So, "t1" is dropped from the error message.

            IMHO, the error message looks still informative.

            ERROR 42000: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '
            		 
            partition x2 tablespace ts2,
            		 
            partition x3 tablespace ts3)' at line 8

            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) added a comment - - edited holyfoot Thank you for your review. I update my patch according to your comments . Please review the updated version: https://github.com/MariaDB/server/commit/88e445850b90db963704076b750bea0b26e555c8 Summary of the changes: Duplications in sql_yacc.yy are removed; The patch is formated by clang-format-diff; The call of link() is removed from the engine_option_value constructions; The error handling for the new operator on engine_option_value is added; Some functions are renamed for consistency; opt_ prefix of some expressions in sql_yacc.yy are revoed for consistency. What has not yet been fixed: - ERROR 42000: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'ts1, + ERROR 42000: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ' The diff above seems to be due to the extension of the syntax. An engine-defined option name can be an arbitrary identity and thus the parser is not able to determine that it is a syntax error until it reads a later token. The function parse_error() just print the last token parsed. So, "t1" is dropped from the error message. IMHO, the error message looks still informative. ERROR 42000: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ' partition x2 tablespace ts2, partition x3 tablespace ts3)' at line 8
            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) added a comment -

            According to the private communication with holyfoot, I slightly fix my patch (redundant err variable in add_engine_part_options() is removed): https://github.com/MariaDB/server/commit/afb81948ac34f37469d43154892cd3b8753bace6

            nayuta-yanagisawa Nayuta Yanagisawa (Inactive) added a comment - According to the private communication with holyfoot, I slightly fix my patch (redundant err variable in add_engine_part_options() is removed): https://github.com/MariaDB/server/commit/afb81948ac34f37469d43154892cd3b8753bace6
            holyfoot Alexey Botchkov added a comment -

            Ok to push as discussed on Slack.

            holyfoot Alexey Botchkov added a comment - Ok to push as discussed on Slack.
            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 added a comment - - edited

            Note that mixing of SE's is not implemented yet (planned in MDEV-22168):

            10.8.0 959a6a723f6b6fb6d9630380c2317b8d51f9e4d8 (Debug)

            		 
            10.8.0-dbg>CREATE TABLE t1 (a INT,b VARCHAR(255),PRIMARY KEY(a)) ENGINE=MyISAM PARTITION BY RANGE(a) (
            		 
                ->     PARTITION pt1 VALUES LESS THAN (100) ENGINE=InnoDB,
            		 
                ->     PARTITION pt2 VALUES LESS THAN MAXVALUE ENGINE=InnoDB);
            		 
            ERROR 1497 (HY000): The mix of handlers in the partitions is not allowed in this version of MariaDB

            Roel Roel Van de Paar added a comment - - edited Note that mixing of SE's is not implemented yet (planned in MDEV-22168 ): 10.8.0 959a6a723f6b6fb6d9630380c2317b8d51f9e4d8 (Debug) 10.8.0-dbg>CREATE TABLE t1 (a INT,b VARCHAR(255),PRIMARY KEY(a)) ENGINE=MyISAM PARTITION BY RANGE(a) ( -> PARTITION pt1 VALUES LESS THAN (100) ENGINE=InnoDB, -> PARTITION pt2 VALUES LESS THAN MAXVALUE ENGINE=InnoDB); ERROR 1497 (HY000): The mix of handlers in the partitions is not allowed in this version of MariaDB
            Roel Roel Van de Paar made changes -
            Roel Roel Van de Paar added a comment -

            Logged MDEV-27545 Feature request: migrate server attributes applicable to engines to the storage engine(s)

            Roel Roel Van de Paar added a comment - Logged MDEV-27545 Feature request: migrate server attributes applicable to engines to the storage engine(s)
            Roel Roel Van de Paar made changes -
            Roel Roel Van de Paar added a comment -

            Logged MDEV-27564 Clearly specify/indicate in the partitioning manual which per-partition options are available

            Roel Roel Van de Paar added a comment - Logged MDEV-27564 Clearly specify/indicate in the partitioning manual which per-partition options are available
            Roel Roel Van de Paar added a comment -

            OK to push. However, I am still running a generic crash test against the feature branch. Results from that will be available around next week Wednesday.

            Roel Roel Van de Paar added a comment - OK to push. However, I am still running a generic crash test against the feature branch. Results from that will be available around next week Wednesday.
            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.