[BUG] MariaDB column defaults are read as MySQL values, so a column with no default shows a default of NULL

[cevheri]

MariaDB and MySQL disagree about what information_schema.COLUMNS.COLUMN_DEFAULT contains, and the app reads it as though they agree.

MySQL reports a VALUE. MariaDB reports an EXPRESSION. So a nullable MariaDB column declared with no default reports COLUMN_DEFAULT as the four characters NULL, and on MySQL those same four characters mean a column whose default is the literal string NULL. The app shows the user a default nobody wrote.

This is live today through getSchema() on the mysql provider, which serves MariaDB as a wire-compatible variant, so a MariaDB user sees it now.

Measured during #789 by the agent implementing that provider's object surface. It deliberately did not fix it: the same read has two callers, getSchema() and the new describeObject(), and repairing only the new one would leave two live surfaces disagreeing about one column for the rest of that epic. getSchema() is removed at the end of #789, at which point there is one reader and one place to fix.

The fix has a clean route that does not require branching on the database type id: the provider now measures the server version at connect time, so the distinction is available as data.

Two cases still to measure before fixing:

• What MariaDB reports for a column whose default really is the string NULL.
• What both engines report for an expression default, for example CURRENT_TIMESTAMP or a generated column.

Done when: a MariaDB column with no default renders as having no default, a MariaDB column defaulting to the literal string NULL renders as that string, and one test pins each against a live server of each family.

[cevheri]

Adding the measurement table, which was dropped when this issue was written from the agent's report. Measured over one probe table on both servers.

column	DDL	MySQL 26.7.0	MariaDB 12.3.2
a	nullable, no default	SQL NULL	the four-character string NULL
c	DEFAULT 'NULL'	the four-character string NULL	'NULL', quotes included
d	DEFAULT 'abc'	abc	'abc', quotes included
f	NOT NULL, no default	SQL NULL	SQL NULL

Two things this table shows that the prose above does not.

Every nullable MariaDB column with no default is reported as having the default NULL, and the string NULL means opposite things on the two servers: on MySQL it is a column whose default really is the four characters, on MariaDB it is a column with no default at all.

And the collision is not limited to NULL. MariaDB returns the expression as written, quotes included, so DEFAULT 'abc' reads back as 'abc' there and abc on MySQL. Any fix has to strip MariaDB's quoting as well as resolve the NULL ambiguity, and a fix that only special-cases NULL leaves every string default wrong by two characters.

[Matthew-Selvam]

Both unmeasured cases are now measured against live servers, plus the quoting edge cases a fix will have to survive. Same probe-table method as the maintainer's table above.

Servers: MySQL 26.7.0 (mysql:latest) and MariaDB 12.3.3 (mariadb:latest), 2026-09-11.

column	DDL	MySQL 26.7.0 COLUMN_DEFAULT	MariaDB 12.3.3 COLUMN_DEFAULT
a	nullable, no default	SQL NULL	the four-character string NULL (confirms the table above)
c	DEFAULT 'NULL'	NULL	'NULL', quotes included (confirms)
d	DEFAULT 'abc'	abc	'abc', quotes included (confirms)
f	NOT NULL, no default	SQL NULL	SQL NULL (confirms)
g	TIMESTAMP DEFAULT CURRENT_TIMESTAMP	CURRENT_TIMESTAMP	current_timestamp() — lower-case, with parens
h	generated column (AS (1+1) STORED)	SQL NULL	the four-character string NULL
i	DEFAULT (CONCAT('x','y'))	concat(_latin1\'x\',_latin1\'y\') — charset-introduced, backslash-escaped quotes	concat('x','y') — as written
j	DEFAULT 42	42	42
k	DEFAULT ''	the empty string	'', quotes included

What this adds beyond the prose above, for whoever implements:

1. The bare string NULL is fully resolvable. A NOT NULL column with DEFAULT 'NULL' reads back quoted ('NULL') on MariaDB — measured today alongside DEFAULT 'abc', which also reads back quoted. So on MariaDB, an unquoted four-character NULL only ever means "no default": either the column is nullable, or EXTRA says STORED GENERATED (case h: a generated column also reads NULL rather than SQL NULL like MySQL does, so checking EXTRA for GENERATED closes that half). IS_NULLABLE alone is not enough; EXTRA is the discriminator.

2. The expression-default case is not symmetric either. CURRENT_TIMESTAMP reads back as CURRENT_TIMESTAMP on MySQL and current_timestamp() on MariaDB — different text, and MariaDB's is an expression shape MySQL never emits. A fix that normalises case to compare will collide with a user who literally wrote a string default that MariaDB then quote-strips into that shape. The strip must be structural (balanced outer quotes only), not case-folded.

3. MySQL's own parenthesised-expression readback is not round-trippable (_latin1\'x\' with backslash escapes), so "show the expression as written" is only achievable on MariaDB. Whatever the fix does for MariaDB quoting, MySQL expression defaults should keep passing through as-is — they are already unquoted values/expressions.

4. The quoting is MariaDB's SQL string literal syntax, so the unescape is '' → '. Measured: DEFAULT 'it''s' reads back 'it''s' and DEFAULT 'NULL''' reads back 'NULL'''. A strip that removes only the outer two characters leaves every string with an embedded quote wrong the same way; DEFAULT 42 and expression defaults arrive unquoted and must not be touched.

5. ORIGINAL_COLUMN_DEFAULT does not exist on either server (checked; ER_BAD_FIELD_ERROR on both) — no information_schema column resolves the ambiguity directly, so the fix really does branch on the measured server identity plus EXTRA, as the issue anticipated.

The disambiguation the measurements support, for a MariaDB server (identity from the VERSION() string, measurable at connect the way probeExplainFormat() already probes there):

• COLUMN_DEFAULT is SQL NULL → no default (unchanged; MySQL's shape for every no-default case).
• EXTRA contains GENERATED → report no default regardless of the string (a generated column has none on either server).
• COLUMN_DEFAULT === 'NULL' unquoted → no default (case a; every real DEFAULT 'NULL' arrives quoted per point 1).
• Otherwise, if the value is a balanced '...' literal → strip the outer quotes and unescape '' → ' (cases c, d, k); everything else (42, current_timestamp(), concat(...)) passes through as written.

Per the issue's own sequencing note, I am deliberately not shipping a patch against getSchema() while #789 is in flight — the fix belongs to the single reader that survives the epic. The measurements are here so it can be written, and its per-family tests planned, without another live-server round.