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 11432831633

Details

• 34 of 36 (94.44%) changed or added relevant lines in 3 files are covered.
• 2 unchanged lines in 2 files lost coverage.
• Overall coverage increased (+0.005%) to 89.392%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/dialect/postgresql.rs	18	19	94.74%
tests/sqlparser_postgres.rs	15	16	93.75%

Files with Coverage Reduction	New Missed Lines	%
src/ast/ddl.rs	1	87.46%
tests/sqlparser_postgres.rs	1	88.57%

Totals
Change from base Build 11429400839:	0.005%
Covered Lines:	30497
Relevant Lines:	34116

---

💛 - 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)
}

[caldwell]

Oh! I somehow missed that UserDefinedTypeRepresentation was an enum. I thought it was a struct which would be more invasive to change, hence the new CreateTypeAsEnum. But yeah, as an enum that's a much better place for it.

I ended up with:

pub enum UserDefinedTypeRepresentation {
    Composite {
        attributes: Vec<UserDefinedTypeCompositeAttributeDef>,
    },
    /// Note: this is PostgreSQL-specific. See <https://www.postgresql.org/docs/current/sql-createtype.html>
    Enum { labels: Vec<Ident> },
}

…so that Enum matches Composite. If you think it should be a real struct instead of the anonymous enum struct I can change it.

[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

[caldwell]

Yes, that can make it much simpler. I also tried using peek to avoid doing "consume, unconsume, consume" but it looks like there's no nice peek_keyword() type function and so it ended up looking like:

if matches!(parser.peek_token().token, Token::Word(Word { keyword: Keyword::CREATE, .. })) {
    parse_create(parser)
}

That's a bit of a mouthful and I ended up just going with your suggestion:

if parser.parse_keyword(Keyword::CREATE) {
    parser.prev_token(); // unconsume the CREATE in case we don't end up parsing anything
    parse_create(parser)
}

[alamb]

@caldwell have you had a chance to consider @iffyio 's suggestions above?

[caldwell]

Apologies, not yet. I'll try to look at it today.

[caldwell]

I amended my commit per @iffyio's suggestions. Thanks for taking the time to look at it and apologies again for taking too long to respond.

[alamb]

I amended my commit per @iffyio's suggestions. Thanks for taking the time to look at it and apologies again for taking too long to respond.

no worries -- thank you!

[caldwell]

I pushed a fix for the formatting test failure.

[alamb]

Looks good to me -- thanks @caldwell

[iffyio]

LGTM!

[alamb]

🚀