Exasol router emitting wrong column-definition packets

In the exasolrouter's result-set column metadata. Every column comes back declared as MYSQL_TYPE_VARCHAR with charset 63 (binary):

python mariadb connector: ('id', 15, 63, 255, 0, 0, False, 129) # type 15, charset 63 = binary
JDBC (same driver DBeaver uses):
col id type=-3(VARBINARY) class=byte[]
col name type=-3(VARBINARY) class=byte[]
col code type=-3(VARBINARY) class=byte[]
col created_at type=-3(VARBINARY) class=byte[]

Meanwhile information_schema.COLUMNS (the repo view, working correctly) tells DBeaver the truth:

id 1 decimal decimal(10,0)
name 2 varchar varchar(400)
code 3 varchar varchar(40)
created_at 4 timestamp timestamp(0)

So DBeaver picks a numeric value handler for id from the catalog metadata, then the JDBC result set hands it a byte[] — no conversion, cell renders [NULL]. The string columns survive because
DBeaver's string handler happily decodes byte[]. The data itself is fine on the wire (getBigDecimal(1) returns 1..5 correctly), which is why it looks like a display-only bug.

Fix: the router must emit a real column-definition packet per column — map the Exasol type to the MySQL type code (DECIMAL/LONGLONG/VAR_STRING/TIMESTAMP) and use the connection's charset, not 63,
for non-binary columns. That code is in MaxScale's exasolrouter C++; it isn't in /r 1 new message (ctrl+End) ↓ can fix it.

you can test dbeaver to our mariadb-exa-demo using docker
replace ./mounts/maxscale/sqlglot.custom.udf with mariadb_preprocessor-b34a65b.sql
replace ./sql/mariadb-compat.sql with mariadb-compat-b34a65b.sql
to test the possible changes for sqlgui compatibility