Add PostgreSQL specfic "CREATE TYPE t AS ENUM (...)" support.

[caldwell]

See: https://www.postgresql.org/docs/current/sql-createtype.html

I implemented this as a separate Statement::CreateTypeAsEnum { name, labels } so it wouldn't be as invasive to the existing Statement::CreateType (which I would imagine helps forwards/backwards compatibility for the crate's users).

I used the PostgreSqlDialect's comment as a blueprint but that means that the generic dialect doesn't get this feature (unless I'm missing something). I didn't see parse_statement() implemented in GenericDialect though I suppose it could be (and call out to other dialects' parse_statement()s). I didn't want to set that precedent without asking.

[alamb]

Thank you for this contribution @caldwell

implemented in GenericDialect though I suppose it could be (and call out to other dialects' parse_statement()s). I didn't want to set that precedent without asking.

I agree -- I think unless there is a good reason to start migrating the code to a different pattern, following the existing patterns is probably the best

cc @iffyio

[coveralls]

Pull Request Test Coverage Report for Build 11221533804

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 34 of 38 (89.47%) changed or added relevant lines in 3 files are covered.
• 4 unchanged lines in 2 files lost coverage.
• Overall coverage decreased (-0.003%) to 89.305%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/ast/mod.rs	3	5	60.0%
src/dialect/postgresql.rs	17	19	89.47%

Files with Coverage Reduction	New Missed Lines	%
tests/sqlparser_postgres.rs	2	88.57%
src/ast/mod.rs	2	82.43%

Totals
Change from base Build 11186281805:	-0.003%
Covered Lines:	30019
Relevant Lines:	33614

---

💛 - Coveralls

[iffyio]

I'm thinking it could make sense to include it as part of the existing CreateType, especially since its already an enum there wouldn't be as much of disadvantage in terms of backwards compatibility? then going forward we'd be able to extend it in a similar manner with future extensions to the statement. something like:

pub enum UserDefinedTypeRepresentation {
    Composite {
        attributes: Vec<UserDefinedTypeCompositeAttributeDef>,
    },
    // new variant
    Enum(CreateTypeEnum)
}

[iffyio]

it might be possible to simplify this if we call prev_token() before calling parse_create? thinking since the latter already returns an Option representing the same result