Skip to content
Snippets Groups Projects
Commit 1701c134 authored by Nikita Pettik's avatar Nikita Pettik Committed by Kirill Yukhin
Browse files

sql: introduce structs assembling DDL arguments during parsing

Parser's rules implementing DDL have a lot in common. For instance,
to drop any entity it is enough to know its name and name of table it is
related to.
Thus, it was suggested to arrange arguments of DDL rules into
hierarchical structure. The root of chain always includes name of table
to be altered: all existing entities are related to some table.  Then
comes one of drop/create/rename rules. Indeed, each DDL operation can be
classified in these terms, at least until we introduce ALTER TABLE ALTER
CONSTRAINT statement. Drop is represented by single structure (as it was
mentioned); rename can be applied only to table; create can be applied
to CONSTRAINT (indexes are considered as constraints) and TRIGGER, which
in turn are different in arguments required to create those objects. And
so forth.

What is more, we are going to introduce ALTER TABLE ADD CONSTRAINT
UNIQUE With new hierarchy we can extend ALTER TABLE statement with ease:
basic structures (alter -> create entity -> create constraint) are the
same for .. FOREIGN KEY/UNIQUE, but the last one will be different.

Finally, during refactoring we've managed to rework syntax for named
constraint, so that now only real constraints (i.e. UNIQUE, PRIMARY KEY,
CHECK and FOREIGN KEY) can have names; others column attributes like
DEFAULT or COLLATE can't.

Needed for #3097
Closes #3820
parent 512aa15b
No related branches found
No related tags found
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment