[LucaCappelletti94]

PostgreSQL accepts GROUP wherever it accepts ROLE in these two statements, but the parser rejected it, so a schema dump containing CREATE GROUP could not be read at all.

The keyword is preserved rather than rewritten to ROLE. It looks like a pure alias in PostgreSQL, but Amazon Redshift has user groups as objects distinct from roles, so folding the two would change what the statement means there.

I will also add ALTER GROUP in a following PR, so as to keep this one smaller.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.57%. Comparing base (424378c) to head (06ba236).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2429      +/-   ##
==========================================
+ Coverage   81.52%   81.57%   +0.04%     
==========================================
  Files          42       42              
  Lines       34205    34244      +39     
  Branches    34205    34244      +39     
==========================================
+ Hits        27885    27933      +48     
+ Misses       2770     2758      -12     
- Partials     3550     3553       +3     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[sabir-akhadov-localstack]

One non-blocking comment inline.

[sabir-akhadov-localstack]

PostgreSQL rejects IF NOT EXISTS for CREATE ROLE too, so this guard only makes the two spellings diverge: CREATE GROUP IF NOT EXISTS g now takes IF as the group name and fails with Expected: end of statement, found: NOT. Either drop the guard to keep parity with ROLE, or reject it with an explicit error.

[LucaCappelletti94]

Now it rejects consistently in both cases