feat: Generalizing CREATE SEQUENCE

[VaggelisD]

Fixes #3072

Generalize CREATE SEQUENCE among Oracle, T-SQL, Postgres, DuckDB, Snowflake.

Design Notes:

• Added UnloggedProperty that exists in Postgres for tables and sequences
• Made parsing of CREATE SEQUENCE order agnostic as dialects had differences between them
• Non-repeating options from Oracle's dialect were encapsulated in an OPTIONS dictionary to simplify parsing
• Future note: It seems that some overlapping options are also parsed in exp.GeneratedAsIdentityColumnConstraint, maybe a refactor between them is favorable?
• 2nd iteration: Added GlobalProperty(post-create properly) and SharingProperty (Oracle post-name) to accommodate for regressions on a command identity , which enabled it's full roundtrip.

Docs

• Postgres
• Oracle
• T-SQL
• DuckDB
• Snowflake

[georgesittas]

Maybe let's try to refactor this by leveraging _parse_properties() (see comment).

[georgesittas]

A few more comments @VaggelisD

[mpf82]

Great idea, but is the idea "only" to allow parsing and generating within the same dialect?

Because, if you also want to support transpiling, by looking at the code and the tests, I am not sure if Oracle's NOCYCLE and NOCACHE are correctly supported or will be correctly transpiled.

Side note: NOSHARD is added twice in CREATE_SEQUENCE

[georgesittas]

Hey Mike, thanks for the review / feedback 👋

is the idea "only" to allow parsing and generating within the same dialect?

For now, that's what we're aiming for. The goal is to allow fine-grained parsing of the CREATE SEQUENCE statement, so that at minimum it can be roundtripped correctly for a given dialect, while also allowing one to analyze its AST. Some basic variants of this statement should already be transpilable as is, but aiming to cover all possible options is too much work, given the number of dialects supporting CREATE SEQUENCE, and the ROI is questionable imo.

Perhaps at some point in the future we could refactor this to control more easily which options / properties are generated per dialect to improve the transpilation.

P.S. just double-checking, but is this related to transpilation, or did you also notice an issue for the Oracle -> Oracle case?

I am not sure if Oracle's NOCYCLE and NOCACHE are correctly supported

[mpf82]

P.S. just double-checking, but is this related to transpilation, or did you also notice an issue for the Oracle -> Oracle case?

Aftert looking again, I guess I mean just transpiling.

I was kinda confused when looking at

        cache = expression.args.get("cache")
        if cache is None:
            cache_str = ""
        elif cache is True:
            cache_str = " CACHE"
        else:
            cache_str = f" CACHE {cache}"

and not seeing NOCACHE in the code and also not seeing a test case.
But other options, such as NOSCALE seem to validate just fine.

So NOCACHE and others must be generated from options = self.expressions(expression, key="options", flat=True, sep=" "), right?
Then I think I understand how it works.

Which also means that if you construct something like "CREATE SEQUENCE seq START WITH 1 NO CACHE NOCACHE CACHE 10" it will also also "validate", correct?
Which is fine, since sqlglot's a parser, not a validator.

[georgesittas]

That's correct, these options are generated using the expressions call you mentioned. And yes - the final statement will also be accepted, which is fine.

[georgesittas]

Few final cleanup suggestions, nice work @VaggelisD.