Expression-Based Index Causes Error During Schema Parsing

[faun]

We’re encountering a Ghostferry schema parsing failure caused by an expression-based index (e.g., CASE WHEN (expired = false) THEN false ELSE NULL END) that produces a NULL for the Column_name field in MySQL’s information_schema, leading Ghostferry to throw “sql: Scan error on column index X, name 'Column_name': converting NULL to string is unsupported.” Because Ghostferry enumerates all tables’ metadata by default—even if they are later blacklisted—it fails on the schema parse. This leads to the following error message during Ghostferry’s initialization:

"sql: Scan error on column index 4, name 'Column_name': converting NULL to string is unsupported"

Environment and Logs
• Ghostferry CopyDB error log excerpt:

time="2025-05-29T19:27:42Z" level=error msg="cannot fetch table schema from source db" database=source_db error="sql: Scan error on column index 4, name "Column_name": converting NULL to string is unsupported" table=example_table tag=table_schema_cache

• The problematic index includes an expression:
(case when (expired = false) then false else NULL end)

Steps to Reproduce

• Create a table with an expression-based index (e.g., using a CASE expression).

CREATE TABLE example_table (
  id bigint NOT NULL AUTO_INCREMENT,
  some_hash varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,
  expired tinyint(1) DEFAULT '0',
  PRIMARY KEY (id),
  UNIQUE KEY expr_based_index (
    some_hash,
    ((CASE WHEN (expired = false) THEN false ELSE NULL END))
  )
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

• Run Ghostferry CopyDB.
• Observe that Ghostferry fails to parse the table’s schema, halting replication.

Expected Behavior
• Ghostferry should either skip tables with expression-based indexes (if blacklisted) or handle the presence of expression-based definitions without failing.

Actual Behavior
• Ghostferry attempts to parse the entire schema—expression-based index columns return NULL as a column name, triggering a fatal “Scan error.”

Thanks in advance for any guidance or fixes you can provide. I’m happy to provide potential patches or share additional logs if needed.

[faun]

It appears this has been fixed in newer versions of go-mysql. I've updated the library version in #394 to see if that fixes this issue.