On a remote server, I have this table definition:

CREATE TABLE `test`.`problem` (

	`dmp` TINYINT(2) UNSIGNED NULL DEFAULT '0',

	`dmps` SET('Asthma','Brustkrebs','COPD','Diabetes1','Diabetes2','KHK') NULL DEFAULT NULL COLLATE 'latin1_german1_ci'

)

COLLATE='latin1_german1_ci'

ENGINE=InnoDB

I try to connect to this table using

create table localtest.problem_connect engine=CONNECT table_type=MYSQL connection='mysql://me:xyzzy@myhost/test/problem'

I then get this error message:

Engine CONNECT failed to discover table `localtest`.`problem_connect` with 'CREATE TABLE whatever (`dmp` TINYINT(2) UNSIGNED DEFAULT 0,`dmps` VARCHAR(61) UNSIGNED) TABLE_TYPE='MYSQL' CONNECTION='mysql://me:xyzzy@myhost/test/problem'' [for Statement "create table problem_connect engine=CONNECT table_type=MYSQL connection='mysql://me:xyzzy@myhost/test/problem'"]

Note that column dmps is declared SET in the original table, but this is converted to VARCHAR(61) in the discovered CONNECT.

This is, as has been pointed out, documented behaviour and, as such, not a bug. Since the underlying data type is, AFAIK, an integer value, this is not a case of "data type unknown to MariaDB", so it should be possible to fully support the SET type through the CONNECT engine. I would like to file a feature request.

It is somewhat unexpected, however, that a table as defined above will actually produce an error message, and not just employ the documented substitution behaviour. If, on the other hand, I remove the first column (dmp), leaving only column DMPS of type SET, then the CONNECT will substitute as documented, without any error mesage. I would assume that whether an error is thrown should not depend on the number of columns. (In particular, the system variable connect_type_conv might be assumed to govern this behaviour, bu as per definition it pertains only to TEXT types but not to SET.)