[Tracking issue] Support database level options and inheritance

[v0y4g3r]

What problem does the new feature solve?

This feature request is a generalization of #1496 which calls for database level TTL.

Tables inside a same database may share some common configurations, like TTL, compaction strategy, etc. It will be convinient if we can set database options when creating databases and allow all tables in that database inherit these options.

What does the feature do?

This feature involves 3 subtasks:

• Allow creating databases with options. Currently CREATE DATABASE does not accept any option Support creating databases with options #3710
• Read database options when table options is not present during table creation
• Allow altering table/database options
• Fuzz tests

Implementation challenges

No response

[killme2008]

@v0y4g3r @evenyag Hi, team, I think this task must be prioritized because the database TTL really matters in users' scenarios, especially for auto-generated tables.

[killme2008]

@v0y4g3r @evenyag Hi, team, I think this task must be prioritized because the database TTL really matters in users' scenarios, especially for auto-generated tables.

I found that database ttl already supported currently:

greptimedb/src/operator/src/statement/ddl.rs

Line 1168 in cc2f7ef

let table_options = merge_options(table_options, schema_opts);

It merge the table options and database options here 👍

[v0y4g3r]

@v0y4g3r @evenyag Hi, team, I think this task must be prioritized because the database TTL really matters in users' scenarios, especially for auto-generated tables.

I found that database ttl already supported currently:

greptimedb/src/operator/src/statement/ddl.rs

Line 1168 in cc2f7ef

let table_options = merge_options(table_options, schema_opts);

It merge the table options and database options here 👍

Yes we now support creating databases with options but still lacks altering database options.