SQL functions for GreptimeDB administration

[killme2008]

What problem does the new feature solve?

We need more functions to query info or do some management jobs in the GreptimeDB. We don't want to add many HTTP APIs for management but just add new SQL functions, because all these functions can be called via select function_xxx() through HTTP /sql API or MySQL/Postgres protocols.

Query functions

• build function to retrieve the server build info. feat: add build() function to return the database build info #2919

Management

• flush_table and flush_region functions to flush memtables of table or region. feat: flush or compact table and region functions #3363
• compact_table and compact_region functions to start a compaction task for table or region. feat: flush or compact table and region functions #3363
• migrate_region to migrate a region from one datanode to another datanode. feat: impl migrate_region and procedure_state SQL function #3325
• procedure_state to query procedure state by its id feat: impl migrate_region and procedure_state SQL function #3325

What does the feature do?

Add functions to query info or do some management jobs in the GreptimeDB

Implementation challenges

No response

[sunng87]

While it's a good idea to use /sql instead of dedicated APIs, using functions for these information introduces issues with permission control.

I have a proposal to put those information behind query functions into information_schema tables. So we can take advantages of:

1. Better permission control: Put these tables in information_schema of default catalog so we can protect it using catalog read/write permission rules.
2. Query: We can use SQL filters and aggregators on data instead of individual functions for frontend/datanode

No idea for those management functions at the moment. But the final design must include permission control or resource isolation mechanism to prevent them from being called with crossing-tenant effect.

[killme2008]

I have a proposal to put those information behind query functions into information_schema tables.

It's a good idea. We have to provide some scaffold function or structure and demo to help people who are interested in contributing these features.