SQLite dialect doesn't support typeless columns

[Xion]

SQLite supports untyped columns in the schema, like in this example:

CREATE TABLE log_data (
    log_id INTEGER NOT NULL,
    key TEXT NOT NULL,
    value,
    PRIMARY KEY (log_id, key),
    FOREIGN KEY(log_id) REFERENCES logs(id) ON DELETE CASCADE
);

Unfortunately, parsing this CREATE TABLE statement with current sqlparser (0.27) results in:

sql parser error: Expected a data type name, found: ,

[AugustoFKL]

@alamb I was wondering; this seems to be a mutually exclusive logic.

Other databases require the data type, while SQLite doesn't.

Is it reasonable to assume that the GenericDialect behavior would be to allow untyped columns...?

[alamb]

Is it reasonable to assume that the GenericDialect behavior would be to allow untyped columns...?

I think if that was technically feasible and not too disruptive, it would be a nice feature

[takluyver]

I think the rules in SQLite are that the symbol after the column name is the data type unless it's one of the keywords introducing a column constraint: CONSTRAINT, PRIMARY, NOT, UNIQUE, CHECK, DEFAULT, COLLATE, REFERENCES, GENERATED, or AS. I'm basing this on the diagrams on this page.

Is it sufficient to allow the check here to be skipped for SQLite:

https://github.com/sqlparser-rs/sqlparser-rs/blob/c887c4e54558db3d3940c23300a384b1752cdeaf/src/parser/mod.rs#L5322

And then make parse_data_type return a Result<Option<DataType>, ParserError>? Or is that too simplistic and will give us keywords like PRIMARY as the data type?

Is the aim with GenericDialect to make a compromise between different SQL dialects - in which case it should probably reject this as it's invalid for most engines - or to parse SQL that's valid for any supported dialect?