feat(cdc): support constant default value for alter table ADD COLUMN

[StrikeW]

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

• Add bind_sql_column_constraints to the support default value during ALTER TABLE process
• Parse the defaultValueExpression field of schema change message to handle default value in auto schema change

We only handle constant default value expression.

"tableChanges": [
    {
        "type": "ALTER",
        "id": "\"mydb\".\"t2\"",
        "table":
        {
            "defaultCharsetName": "utf8mb4",
            "primaryKeyColumnNames":
            [
                "id"
            ],
            "columns":
            [
                {
                    "name": "v5",
                    "jdbcType": 8,
                    "nativeType": null,
                    "typeName": "DOUBLE",
                    "typeExpression": "DOUBLE",
                    "charsetName": null,
                    "length": 5,
                    "scale": 2,
                    "position": 6,
                    "optional": true,
                    "autoIncremented": false,
                    "generated": false,
                    "comment": null,
                    "defaultValueExpression": "1.0",
                    "enumValues": null
                }
            ],
            "comment": null
        }
    }
]

Checklist

• I have written necessary rustdoc comments
• I have added necessary unit tests and integration tests
• I have added test labels as necessary. See details.
• I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features Sqlsmith: Sql feature generation #7934).
• My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
• All checks passed in ./risedev check (or alias, ./risedev c)
• My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

• My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

• My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note

If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

[BugenZhao]

What do you mean by "the default value column is not set in the column sql definition"? Can you elaborate more by giving an example?

[StrikeW]

You can take a look of get_new_table_definition_for_cdc_table.
Because auto schema change doesn't submit the new ColumnDef to frontend, we submit the ColumnCatalog parsed from message. So after mutation the definition of original catalog, there is no DEFAULT expr in the modified definition.

[BugenZhao]

Then shall we consider filling the DEFAULT expr clause when inferring a ColumnDef from ColumnCatalog?

[StrikeW]

• How to do it? I didn't find a simple way to convert a ColumnCatalog back to ColumnDef
• We already have column catalog on hand, so I think it is unnecessary to convert back to ColumnDef and parse to ColumnCatalog again.

[BugenZhao]

• I didn't find a simple way to convert a ColumnCatalog back to ColumnDef

IIUC we're essentially converting ColumnCatalog to ColumnDef here, though only data type is taken into consideration thus incomplete.

risingwave/src/frontend/src/handler/alter_table_column.rs

Lines 113 to 114 in c59b3eb

	let ty = to_ast_data_type(col.data_type())?;
	new_column_defs.push(ColumnDef::new(col.name().into(), ty, None, vec![]));

• I think it is unnecessary to convert back to ColumnDef and parse to ColumnCatalog again

Theoretically yes, but what will the response look like when user querying SHOW CREATE TABLE cdc_table now?

[StrikeW]

IIUC we're essentially converting ColumnCatalog to ColumnDef here, though only data type is taken into consideration thus incomplete.

Specially, I mean the ColumnOption part.

Theoretically yes, but what will the response look like when user querying SHOW CREATE TABLE cdc_table now?

The DEFAULT expr won't show up in the sql. And when create a new table, we won't capture the default value definition from upstream, I think the output is consistent in both case.

[BugenZhao]

And when create a new table, we won't capture the default value definition from upstream

Would this be somehow inconsistent and surprising to users? Note that default values are also used when performing DML.

[StrikeW]

And when create a new table, we won't capture the default value definition from upstream

Would this be somehow inconsistent and surprising to users? Note that default values are also used when performing DML.

For the case of auto schema mapping (create table t (*)), we can improve the feature in future to get the default value from upstream.
For the table with column definitions manually specified by user, I think they should also specify the default column by hand in the DDL.

[BugenZhao]

For the case of auto schema mapping (create table t (*)), we can improve the feature in future to get the default value from upstream.

Sure. Can you please track it in an issue?

[StrikeW]

Done. #18359