feat: support pg_namespace, pg_class and related psql command

[J0HN50N133]

I hereby agree to the terms of the GreptimeDB CLA.

Refer to a related PR or issue link (optional)

#3560

What's changed and what's your intention?

!!! DO NOT LEAVE THIS BLOCK EMPTY !!!

Please explain IN DETAIL what the changes are in this PR and why they are needed:

• Summarize your change
  Add pg_catalog.pg_namespace and pg_catalog.pg_class. Now we can use \d, \dt, \dv and all
  related psql commands.
• Describe any limitations of the current code:
  1. Column oid in pg_catalog.pg_namespace need u32 values to identify namespace(i.e. schema in greptime), but there is no numeric schema id. So we just use schema_name as identifier. This workaround may introduce potential incompatibility with the existed pg eco.
  2. pg_catalog.pg_get_userbyid always return empty string, since we don't have UserId to get UserInfo.
     for details see: Compatible with Postgres system catalog #3560 (comment)

Checklist

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

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

---

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

Share

• X
• Mastodon
• Reddit
• LinkedIn

Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai generate interesting stats about this repository and render them as a table.
  • @coderabbitai show all the console.log statements in this repository.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (invoked as PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[J0HN50N133]

@tisonkun can you take a look?

[codecov]

Codecov Report

Attention: Patch coverage is 27.60736% with 236 lines in your changes missing coverage. Please review.

Project coverage is 84.60%. Comparing base (92d6d4e) to head (97a3435).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4428      +/-   ##
==========================================
- Coverage   84.97%   84.60%   -0.37%     
==========================================
  Files        1076     1081       +5     
  Lines      192585   192910     +325     
==========================================
- Hits       163653   163219     -434     
- Misses      28932    29691     +759     

[J0HN50N133]

@tisonkun Let's push forward this pr to avoid extra burden to keep track with main branch.

[killme2008]

Great work! I'll give a review today. Thank you.

[killme2008]

Column oid in pg_catalog.pg_namespace need u32 values to identify namespace(i.e. schema in greptime), but there is no numeric schema id. So we just use schema_name as identifier. This workaround may introduce potential incompatibility with the existed pg eco

A question or proposition: could we use a hash value of the schema name(if it is a perfect hash function, AKA no conflicts)?

[killme2008]

Thanks a lot. LGTM.

[tisonkun]

Thanks for your contribution! Merging ...

[killme2008]

Column oid in pg_catalog.pg_namespace need u32 values to identify namespace(i.e. schema in greptime), but there is no numeric schema id. So we just use schema_name as identifier. This workaround may introduce potential incompatibility with the existed pg eco

A question or proposition: could we use a hash value of the schema name(if it is a perfect hash function, AKA no conflicts)?

@J0HN50N133 Could you consider this suggestion? Using schema_name as schema id is a potential issue, the data type is totally different.

[J0HN50N133]

Column oid in pg_catalog.pg_namespace need u32 values to identify namespace(i.e. schema in greptime), but there is no numeric schema id. So we just use schema_name as identifier. This workaround may introduce potential incompatibility with the existed pg eco

A question or proposition: could we use a hash value of the schema name(if it is a perfect hash function, AKA no conflicts)?

@J0HN50N133 Could you consider this suggestion? Using schema_name as schema id is a potential issue, the data type is totally different.

@killme2008
A perfect hash is hard to find, but I have a workaround. If we can make sure that the numeric id is only used in catalog module, we could use hash and handle the collision inside pg_catalog. Here's the detail:

1. we hash a schema name to get a u32 id.
2. If no collision's found, that's good, put this id into an id_set
3. If collision's found, rehash the u32 id until no collision.
   But this method may cause the id change along with schema creation. Suppose there is a schema a. At first, hash(a) is good, no collision's found. Then we create another schema b, which hash value collide with a and is hashed before a. Then a's id will be a different value.

Or we can create a new metadata manager to maintain the schema id.

[killme2008]

Column oid in pg_catalog.pg_namespace need u32 values to identify namespace(i.e. schema in greptime), but there is no numeric schema id. So we just use schema_name as identifier. This workaround may introduce potential incompatibility with the existed pg eco

A question or proposition: could we use a hash value of the schema name(if it is a perfect hash function, AKA no conflicts)?

@J0HN50N133 Could you consider this suggestion? Using schema_name as schema id is a potential issue, the data type is totally different.

@killme2008 A perfect hash is hard to find, but I have a workaround. If we can make sure that the numeric id is only used in catalog module, we could use hash and handle the collision inside pg_catalog. Here's the detail:

1. we hash a schema name to get a u32 id.
2. If no collision's found, that's good, put this id into an id_set
3. If collision's found, rehash the u32 id until no collision.
   But this method may cause the id change along with schema creation. Suppose there is a schema a. At first, hash(a) is good, no collision's found. Then we create another schema b, which hash value collide with a and is hashed before a. Then a's id will be a different value.

Or we can create a new metadata manager to maintain the schema id.

I think it can work currently. The best way is to add a schema id in metadata, let's do the refactor in the future. @fengjiachun
In fact, there will not be so many schemas in actual deployments except the cloud.

[J0HN50N133]

Column oid in pg_catalog.pg_namespace need u32 values to identify namespace(i.e. schema in greptime), but there is no numeric schema id. So we just use schema_name as identifier. This workaround may introduce potential incompatibility with the existed pg ecopg_catalog.pg_namespace 表中的列 oid 需要 u32 值来标识命名空间（即 Greptime 中的 schema），但目前没有数字形式的 schema ID。因此，我们暂时使用 schema_name 作为标识符。这种权宜之计可能会引入与现有 PostgreSQL 生态的不兼容性。

A question or proposition: could we use a hash value of the schema name(if it is a perfect hash function, AKA no conflicts)?一个问题或提议：我们能否使用模式名称的哈希值（如果它是一个完美的哈希函数，即无冲突）？

@J0HN50N133 Could you consider this suggestion? Using schema_name as schema id is a potential issue, the data type is totally different.您是否考虑过这个建议？使用 schema_name 作为模式 ID 可能存在问题，因为数据类型完全不同。

@killme2008 A perfect hash is hard to find, but I have a workaround. If we can make sure that the numeric id is only used in catalog module, we could use hash and handle the collision inside pg_catalog. Here's the detail:完美哈希难以寻觅，但我有一套变通方案。若能确保数值 ID 仅在 catalog 模块内使用，我们便可采用哈希并在 pg_catalog 内部处理冲突。以下是详细方案：

1. we hash a schema name to get a u32 id.我们通过哈希一个模式名称来获取一个 u32 ID。
2. If no collision's found, that's good, put this id into an id_set如果没有发现冲突，那就好，将此 ID 放入 id_set
3. If collision's found, rehash the u32 id until no collision.如果发现冲突，重新哈希 u32 ID 直到无冲突。
   But this method may cause the id change along with schema creation. Suppose there is a schema a. At first, hash(a) is good, no collision's found. Then we create another schema b, which hash value collide with a and is hashed before a. Then a's id will be a different value.但这种方法可能导致 ID 随着模式创建而改变。假设存在一个模式 a 。起初， hash(a) 是良好的，未发现冲突。随后，我们创建另一个模式 b ，其哈希值与 a 发生冲突，并且在 a 之前进行哈希处理。那么 a 的 ID 将会是一个不同的值。

Or we can create a new metadata manager to maintain the schema id.或者，我们可以创建一个新的元数据管理器来维护模式 ID。

I think it can work currently. The best way is to add a schema id in metadata, let's do the refactor in the future. 我认为目前它可以正常工作。最佳方案是在元数据中添加一个模式 ID，我们将来再进行重构。@fengjiachun In fact, there will not be so many schemas in actual deployments except the cloud.实际上，除了云端，实际部署中并不会存在如此多的架构。

@killme2008 Got it. I'll implement the workaround tomorrow.