-
-
Notifications
You must be signed in to change notification settings - Fork 110
Added support to PostgreSQL identity column #277
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
Conversation
- Connection.transaction - fails simple SELECT COUNT(*) and I do not want to deal with
f8e1e59 to
4862e4d
Compare
|
I would stay with SERIAL support, PostgreSQL 9.6 has no identities and is still supported (well, to November 2021). There is one bug in this PR, missing parenthesis around new OR operands. In that case, it marks autoincrement column event if not primary key. Sorry, there is no test for it. Please, fix your commit (or I can do that, I'll leave you as author but signature will be missing). And I have prepeared test too. |
|
One day, query may be siplified to use |
Yup, also the latter line may be simplified by using pg_get_serial_sequence() when they fix problems with multiple schemas. Thanks for the review :-) |
|
Thank you. I squashed the commits and merged them as c498d8c |
(Sorry for the new PR but I deleted the old branch and repository)
Since PostgreSQL 10, identity columns are recommended instead of serial types as stated in the documentation (and serial types are even discouraged here).
In the old PR
a.attidentity = ANY (ARRAY['a', 'd'])andpg_get_serial_sequence()were used. While the first only caused problem with older PostgreSQL, the latter has (known) issues with multiple schemas. The best way was to directly query pg_catalog (that is not something trival).Tests are successful (here) both with serial types and identity columns. Does it make sense to keep both or we will update the current ones to use just the new identity column?