Idea: SQL DDL as an input source (optional extra, not core)

[FabianClemenz]

💡 Idea: support SQL DDL as an input source — as an optional extra, not in core

Could erdify also read CREATE TABLE … SQL DDL (alongside the Python ORM sources) and render it to the same ERDs?

Architecturally: yes, it fits

erdify's EntityInfo/FieldInfo model and the emitters (PlantUML / Mermaid / JSON / HTML) are source-agnostic — the parser is just a frontend. A SQL frontend (CREATE TABLE → EntityInfo) would dock on cleanly.

But it must NOT go in the core

Two hard reasons:

1. It breaks "zero runtime dependencies" + stdlib-ast. Python's ast can't parse SQL. A hand-rolled SQL parser is a trap — DDL is dialect-chaotic (Postgres/MySQL/SQLite/T-SQL, inline vs. table-level FKs, quoted identifiers, constraints) and would be wrong on real-world schemas. Doing it properly needs a real parser like sqlglot — a genuine dependency.
2. SQL→ERD is a crowded space (dbdiagram.io, SchemaSpy, sqltoerdiagram.com, …). erdify's edge is precisely the Python ORM, no DB connection, no imports angle — not SQL, where it would have no differentiation.

Proposed shape (if pursued)

An optional extra so the core stays zero-dependency:

pip install erdify[sql]   # pulls sqlglot only when you want SQL input

.sql files become a new source kind, parsed via sqlglot into the existing EntityInfo model; everything downstream (formats, --sources, --check, config) is reused.

Open questions

• Is there real demand, or is the Python-ORM focus enough?
• Which dialects matter first?
• Discovery: which files (*.sql? a --sql flag pointing at a schema dump)?

👉 Thoughts and use cases welcome. Decision so far: keep it out of the zero-dependency core; optional extra at most.