Support MySQL UNIQUE table constraint

[Nikita-str]

Fix to #1149 and some more.

Allow to parse [CONSTRAINT [name]] UNIQUE [INDEX | KEY] [index_name] [index_type] (<columns>) [index_option]s ... as it say in the specification.

Also unallow CONSTRAINT bar INDEX ind (foo) for table constraint; as it was said INDEX ind (foo) form of table constraint was found only in MySQL, but in MySQL allowed only INDEX ind (foo) without CONSTRAINT bar before it.

Some remarks:

• Maybe it have sense to split TableConstraint::Unique into TableConstraint::Unique & TableConstraint::Primary?
• In this PR was created IndexOption struct, and maybe it can be unite with some another structure, I unsure.
• In MySQL CONSTRAINT a UNIQUE b (x) will set b and for index_name(in MySQL you can obtain it by SELECT index_name FROM INFORMATION_SCHEMA.STATISTICS) and for constraint_name(in MySQL you can obtain it by SELECT constraint_name FROM INFORMATION_SCHEMA.TABLE_CONSTRAINTS) so I don't sure if names really needed to be splitted.

[coveralls]

Pull Request Test Coverage Report for Build 8621622983

Details

• 186 of 198 (93.94%) changed or added relevant lines in 3 files are covered.
• 3 unchanged lines in 1 file lost coverage.
• Overall coverage increased (+0.03%) to 88.034%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/ast/ddl.rs	44	49	89.8%
src/parser/mod.rs	52	59	88.14%

Files with Coverage Reduction	New Missed Lines	%
src/parser/mod.rs	3	82.88%

Totals
Change from base Build 8588850954:	0.03%
Covered Lines:	20939
Relevant Lines:	23785

---

💛 - Coveralls

[alamb]

Maybe it have sense to split TableConstraint::Unique into TableConstraint::Unique & TableConstraint::Primary?

Yes, I agree this would make more sense than trying to combine UNIQUE and PRIMARY KEY syntaxes together

Are you willing to make this change? I am really sorry for the delay in reviewing

[Nikita-str]

I do the split, but now I'm unsure that it was good idea, because MySql specification say that there no [index_name] in PRIMARY KEY variant but actually compiler take CREATE TABLE table_name (x INT, CONSTRAINT name PRIMARY KEY index_name (x)); as valid query. So PRIMARY KEY and UNIQUE have less differences than I expected.

Their similarity is visible in tests during creation and during assertion of inner structure.

But still maybe when they are separate it's more expected by an user, idk.

[Nikita-str]

Also during last changes I add some functions like display_constraint_name but for Option<T>.

For example instead next

if let Some(exclude) = &self.opt_exclude {
    write!(f, " {exclude}")?;
}
if let Some(except) = &self.opt_except {
    write!(f, " {except}")?;
}
if let Some(rename) = &self.opt_rename {
    write!(f, " {rename}")?;
}
if let Some(replace) = &self.opt_replace {
    write!(f, " {replace}")?;
}

you can write

write!(
    f, 
    "{}{}{}{}",
    display_option_spaced(&self.opt_exclude),
    display_option_spaced(&self.opt_except),
    display_option_spaced(&self.opt_rename),
    display_option_spaced(&self.opt_replace),
)?;

I think it will be pretty convenient for fmt

[alamb]

But still maybe when they are separate it's more expected by an user, idk.

I agree -- the sqlparser's crate aim is to preserve syntax and it is up downstream consumers to decide how to handle the semantics (e.g if they want to treat UNIQUE and PRIMARY the same)

[alamb]

Thank you very much @Nikita-str -- I pushed a few small comment improvements and then I'll merge this PR in.

Thanks again and sorry for the delay in reviewing

[alamb]

👍 I agree this is very nice

[alamb]

Thanks again @Nikita-str