Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for ALTER SEQUENCE [ sequence flags ] #9437

Closed
7 tasks done
lukaseder opened this issue Oct 25, 2019 · 3 comments
Closed
7 tasks done

Add support for ALTER SEQUENCE [ sequence flags ] #9437

lukaseder opened this issue Oct 25, 2019 · 3 comments

Comments

@lukaseder
Copy link
Member

lukaseder commented Oct 25, 2019

We currently do not have any way to alter sequence flags, except for the START WITH flag, which can be reset using ALTER SEQUENCE .. RESTART WITH or ALTER SEQUENCE .. RESTART.

Oracle, for example, supports this syntax:

image

We should allow for altering the following flags as well:

@knutwannheden
Copy link
Contributor

Looking at AlterSequenceStep it strikes me as slightly odd that it has a generic type parameter <T extends Number>. To be consistent with the CreateSequenceFlagsStep API, I would propose to remove that generic type parameter. This would however not be a source compatible change (or is the assignment of Step APIs exempt from our source compatibility rules?), which isn't nice.

@lukaseder
Copy link
Member Author

I propose the inverse: #9465 Adding the generic type parameter to CreateSequenceFlagsStep<T extends Number>

knutwannheden added a commit that referenced this issue Oct 30, 2019
Adds the new `AlterSequenceFlagsStep` as a supertype to
`AlterSequenceStep`, which allows setting and clearing various flags
like `MINVALUE` and `CACHE`.
lukaseder added a commit that referenced this issue Oct 31, 2019
Also, rename parameter from constant to value
@knutwannheden
Copy link
Contributor

As discussed, the new AlterSequenceFlagsStep should be defined without generic type parameter, as CreateSequenceFlagsStep.

knutwannheden added a commit that referenced this issue Nov 20, 2019
Using generics here causes problems given the current signatures on
`DSLContext`, where the return type explicitly uses `BigInteger` as the
generic type parameter.
knutwannheden added a commit that referenced this issue Nov 20, 2019
PostgreSQL only understands the `CACHE` clause and `CACHE 1` effectively
means `NO CACHE`.
3.13 DDL interpretation automation moved this from To do to Done Nov 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

No branches or pull requests

2 participants