feat: support ALTER TABLE ... MODIFY COLUMN ... ...

[KKould]

I hereby agree to the terms of the GreptimeDB CLA.

Refer to a related PR or issue link (optional)

#3517
GreptimeTeam/greptime-proto#149

What's changed and what's your intention?

Support: alter table xxx modify column xxx xxx
https://dev.mysql.com/doc/refman/8.0/en/alter-table.html

public=> CREATE TABLE test(id INTEGER PRIMARY KEY, i INTEGER NULL, j TIMESTAMP TIME INDEX, k BOOLEAN);
OK 0
public=> ALTER TABLE test MODIFY COLUMN I STRING;
OK 0
public=> DESCRIBE test;
 Column |         Type         | Key | Null | Default | Semantic Type 
--------+----------------------+-----+------+---------+---------------
 id     | Int32                | PRI | YES  |         | TAG
 i      | String               |     | YES  |         | FIELD
 j      | TimestampMillisecond | PRI | NO   |         | TIMESTAMP
 k      | Boolean              |     | YES  |         | FIELD
(4 rows)

Checklist

• I have written the necessary rustdoc comments.
• I have added the necessary unit tests and integration tests.
• This PR does not require documentation updates.

[codecov]

Codecov Report

Attention: Patch coverage is 89.16667% with 26 lines in your changes are missing coverage. Please review.

Project coverage is 85.29%. Comparing base (701aba9) to head (caac6d4).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3796      +/-   ##
==========================================
- Coverage   85.64%   85.29%   -0.35%     
==========================================
  Files         954      954              
  Lines      163037   163253     +216     
==========================================
- Hits       139625   139246     -379     
- Misses      23412    24007     +595     

[evenyag]

Mostly looks good.

[killme2008]

Good job! But why not use the common SQL syntax?

ALTER TABLE table_name
MODIFY COLUMN column_name datatype;

It would be better that the user doesn't need to learn a new syntax.

[evenyag]

But why not use the common SQL syntax?

This is the syntax PostgreSQL currently uses.
https://www.postgresql.org/docs/current/sql-altertable.html

ALTER TABLE distributors
    ALTER COLUMN address TYPE varchar(80),
    ALTER COLUMN name TYPE varchar(100);

[killme2008]

But why not use the common SQL syntax?

This is the syntax PostgreSQL currently uses. https://www.postgresql.org/docs/current/sql-altertable.html

ALTER TABLE distributors
    ALTER COLUMN address TYPE varchar(80),
    ALTER COLUMN name TYPE varchar(100);

Yes, but MySQL, Oracle, and SQLServer are using modify column.

[KKould]

tips: sqlparser-rs already supports modify column: sqlparser-rs/sqlparser-rs#1216

[MichaelScofield]

Create an issue here for reminding us the docs after this whole feature is done.

[WenyXu]

Hi @KKould There are some conflicts

[WenyXu]

tips: sqlparser-rs already supports modify column: sqlparser-rs/sqlparser-rs#1216

Is it possible to upgrade the SQL parser-rs to the latest?

[KKould]

I created PR: GreptimeTeam/sqlparser-rs#11 to support modify column

[evenyag]

If the CI failure in GreptimeTeam/sqlparser-rs#11 is easy to fix. We could implement the final syntax in this PR. @KKould Could you please take a look?

[KKould]

If the CI failure in GreptimeTeam/sqlparser-rs#11 is easy to fix. We could implement the final syntax in this PR. @KKould Could you please take a look?

I checked before and it seems that these errors are caused by other PRs, not this PR.

[Taylor-lagrange]

The pr should be open on v0.44.x instead of the main branch, because the sqlparser code will be synchronized with datafusion' sqlparser code regularly. However, I still recommend not to change the keywords and use parser directly to identify the token to avoid conflict when sync upstream sqlparser later.