Improve column specification support in a generic way

[seancorfield]

DDL can be extremely vendor-specific and that means that column specifications (in CREATE/ALTER `TABLE commands, for example) can contain pretty much anything.

You can't even say a "column specification" always begins with a column name since PRIMARY KEY and CONSTRAINT and all sorts of things can also appear (detecting the difference between a column specification and a constraint etc specification might be possible to "switch modes" but it's probably easier to just handle those as "special syntax" which is pretty much how things work today).

Part of the problem here is the variability of the syntax means that you can get any of the following sorts of constructs:

• SQL-KEYWORD
• entity_name
• SQL-KEYWORD entity_name
• SQL-KEYWORD(entity_name)
• SQL-KEYWORD entity_name(other_entity)

There's existing generic machinery to distinguish between [:sql-keyword :entity-name] (producing SQL KEYWORD(entity_name)) and [:'entity-name :other-entity] (producing entity_name(other_entity)) but there's no generic machinery to distinguish between [:sql-keyword :entity-name] producing SQL KEYWORD entity_name or SQL KEYWORD(entity_name).

We can assume a simple ident in the first slot is entity-name and thereafter we can assume there will always be (at least) one SQL-KEYWORD in front of any entity-name (I think? I can't think of any syntax where we might get multiple entity names that aren't in a list?). If it does happen in some context, the :' prefix can be used to force an entity name (instead of a SQL keyword).

So...

How do we resolve the SQL KEYWORD entity_name vs SQL KEYWORD(entity_name) ambiguity?

[seancorfield]

I deliberately punted on the SQL KEYWORD entity_name case for now. Specific keywords can be added to the Special Syntax handling as function-1 (or function-1-opt) as they come up.