feat(starrocks): add full support for partitions

[petrikoro]

Fixes #6803

Description

This PR adds comprehensive support for StarRocks partitioning syntax including:

• Expression-based partitioning (PARTITION BY expr1, expr2): https://docs.starrocks.io/docs/table_design/data_distribution/expression_partitioning/
• LIST partitioning (PARTITION BY LIST (cols) (...)): https://docs.starrocks.io/docs/table_design/data_distribution/list_partitioning/
• RANGE partitioning with explicit values (PARTITION BY RANGE (cols) (PARTITION ... VALUES LESS THAN ...)): https://docs.starrocks.io/docs/table_design/data_distribution/dynamic_partitioning/#example
• RANGE partitioning with dynamic ranges (PARTITION BY RANGE (cols) (START ... END ... EVERY ...)): https://docs.starrocks.io/docs/table_design/data_distribution/dynamic_partitioning/#example

Previously, multi-expression partitioning and LIST partitioning were not supported.

Examples

Expression-based partitioning:

-- Single expression
CREATE TABLE t (col DATE) PARTITION BY DATE_TRUNC('DAY', col)

-- Multiple expressions  
CREATE TABLE t (col1 STRING, col2 BIGINT) PARTITION BY FROM_UNIXTIME(col2, '%Y%m%d'), col1

LIST partitioning:

-- Single column
CREATE TABLE t (city STRING) PARTITION BY LIST (city) (
    PARTITION pLA VALUES IN ('Los Angeles'),
    PARTITION pSF VALUES IN ('San Francisco')
)

-- Multi-column
CREATE TABLE t (dt DATE, city STRING) PARTITION BY LIST (dt, city) (
    PARTITION p1 VALUES IN (('2022-04-01', 'LA'), ('2022-04-01', 'SF'))
)

RANGE partitioning with explicit values:

CREATE TABLE t (col DATE) PARTITION BY RANGE (col) (
    PARTITION p1 VALUES LESS THAN ('2020-01-31'),
    PARTITION p2 VALUES LESS THAN ('2020-02-29'),
    PARTITION p_max VALUES LESS THAN (MAXVALUE)
)

-- With expression
CREATE TABLE t (col STRING) PARTITION BY RANGE (STR2DATE(col, '%Y-%m-%d')) (
    PARTITION p1 VALUES LESS THAN ('2021-01-01'),
    PARTITION p2 VALUES LESS THAN ('2021-01-02')
)

RANGE partitioning with START/END/EVERY:

CREATE TABLE t (col DATE) PARTITION BY RANGE (col) (
    START ('2019-01-01') END ('2021-01-01') EVERY (INTERVAL 1 YEAR),
    START ('2021-01-01') END ('2021-05-01') EVERY (INTERVAL 1 MONTH)
)

See more in tests/dialects/test_starrocks.py

Testing

All syntax variations have been validated against a local StarRocks instance (tested on StarRocks 4.0.2 and 3.5.0).

[geooo109]

@petrikoro thank you for the PR, great work.

I have some suggestions.

1. There is a similar implementation in doris.py that we should check in order to factor out some code. ( a relevant commit here: 73c2894 )
2. As I checked MySQL has some similar PARTITION BY syntax that we currently don't cover (same cases with the ones you posted without the dynamic one because it isn't supported in MySQL e.g. https://dev.mysql.com/doc/refman/8.4/en/partitioning-range.html ). We can push some implemenation in this dialect and inherit + implement some extra logic in the derived dialects, thus adding functionallity in the MySQL dialect + removing extra code from the deried dialects (Doris, Starrocks).
3. For common patterns between Doris and Starrocks that don't exist in MySQL we can factor out in the Dialect class.

I will add some extra inline comments for help.

[georgesittas]

Hey @petrikoro 👋

Are you planning to take this to the finish line?

[petrikoro]

Hey @petrikoro 👋

Are you planning to take this to the finish line?

Hi 👋

Sure, I plan to get back to PR tomorrow. Thanks for the suggestions @geooo109!

[petrikoro]

@petrikoro thank you for the PR, great work.

I have some suggestions.

1. There is a similar implementation in doris.py that we should check in order to factor out some code. ( a relevant commit here: 73c2894 )
2. As I checked MySQL has some similar PARTITION BY syntax that we currently don't cover (same cases with the ones you posted without the dynamic one because it isn't supported in MySQL e.g. https://dev.mysql.com/doc/refman/8.4/en/partitioning-range.html ). We can push some implemenation in this dialect and inherit + implement some extra logic in the derived dialects, thus adding functionallity in the MySQL dialect + removing extra code from the deried dialects (Doris, Starrocks).
3. For common patterns between Doris and Starrocks that don't exist in MySQL we can factor out in the Dialect class.

I will add some extra inline comments for help.

Hi! Take a look at a477f75, did I get that right?

[geooo109]

@petrikoro thank you very much, will check it soon.

[geooo109]

Nice work!! left some comments.