Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.8(EOL)
-
None
Description
10.8 05050867 |
MariaDB [test]> create table t (a int) partition by hash(a) (partition p1 encrypted= "i will think about it"); |
Query OK, 0 rows affected (0.034 sec) |
|
MariaDB [test]> create or replace table t (a int) partition by hash(a) (partition p1 encrypted= 42); |
Query OK, 0 rows affected (0.062 sec) |
On the table level both would have thrown ER_BAD_OPTION_VALUE.
The practical side of the problem is that values which look meaningful but are in fact incorrect may bypass validation.
For example, on a server without configured encryption, both of
create table t (a int) encrypted=yes; |
create table t (a int) encrypted=1; |
will fail – the first one with ER_CANT_CREATE_TABLE and a bunch of warnings, because there is no encryption available, and the second one with ER_BAD_OPTION_VALUE because "1" is in fact not a valid value.
However, with the same options on the partition level
create table t (a int) partition by hash(a) (partition p0 encrypted=yes); |
create table t (a int) partition by hash(a) (partition p0 encrypted=1); |
the first one will again fail with ER_CANT_CREATE_TABLE, but the second one will work, giving the impression that an encrypted partition has been created.
Attachments
Issue Links
- is caused by
-
MDEV-5271 Support engine-defined attributes per partition
- Closed