fix: unify varchar format_type display with PostgreSQL

[jetjinser]

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

What's changed and what's your intention?

Make format type display of RisingWave consistent with PostgreSQL.
The original purpose of this PR is to fix the problem that the varchar type in superset cannot be recognized.

superset uses sqlalchemy as the ORM, and the different format type from PostgreSQL makes the type unrecognizable to sqlalchemy.

The inconsistencies are:

SELECT format_type(1043, '-1');

result of RisingWave: varchar; of PostgreSQL: character varying.

SqlAlchemy test:

CREATE TABLE test (a int, b varchar);

from sqlalchemy import create_engine
from sqlalchemy import inspect

def main():
    # engine = create_engine("postgresql://jinser:pssswd@localhost:5432/playground") # PostgreSQL
    engine = create_engine("postgresql://root@localhost:4566/dev") # RisingWave
    inspector = inspect(engine)

    columns = inspector.get_columns("test", "public")
    for column in columns:
        print(column)

related #9938.

Checklist

• I have written necessary rustdoc comments
• I have added necessary unit tests and integration tests
• 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

[BugenZhao]

LGTM. Would you please help to fix failed e2e tests, while also adding this query to e2e_test/batch/functions/format_type.slt.part?

SELECT format_type(1043, '-1');

[jetjinser]

Hi, should work fine now.

[BugenZhao]

Where do we depend on this? 👀

[jetjinser]

Are you asking what program relies on this format type? If so, then here it it type deserialization of SqlAlchemy.
Hum, if you're asking if there are any program that already rely on this varchar format type, I don't know 🤕.

[BugenZhao]

I've confirmed that from_str is only used in tests (like expr::build_from_pretty), so it's not a big deal. However, what about also changing this for consistency? Take int32 as an example of how to accept both:

risingwave/src/common/src/types/mod.rs

Line 108 in 01c7c2b

#[from_str(regex = "(?i)^integer$|^int$|^int4$")]

[jetjinser]

Is this what you mean:

#[from_str(regex = "(?i)^character varying$|^varchar$")]

[jetjinser]

committed it, plz review.

[codecov]

Codecov Report

Merging #12648 (68b2df2) into main (a46292e) will decrease coverage by 0.02%.
Report is 31 commits behind head on main.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main   #12648      +/-   ##
==========================================
- Coverage   69.30%   69.28%   -0.02%     
==========================================
  Files        1470     1470              
  Lines      241283   241286       +3     
==========================================
- Hits       167212   167174      -38     
- Misses      74071    74112      +41     

Flag	Coverage Δ
rust	69.28% <100.00%> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
src/common/src/types/mod.rs	72.97% <100.00%> (+0.09%)	⬆️
src/frontend/src/handler/show.rs	26.16% <100.00%> (ø)

... and 4 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more