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
Fix updateable result set when there are primary keys and unique keys #2228
Conversation
…ue keys Fix issues introduced in PR# 2199 causing problems when updating tables with PK and UK. Originally updateable result set supports only primary keys, wich the forementioned change and this fix unique keys are also eligible to enable updateable result set. This change will find the better suited primary or unique key that has all the available columns in the query, but if no match is found it will continue to fail as it used to. Closes issue 2196
@davecramer Created this PR that covers issues mentioned before |
Add missing @nullable annotations to primaryKeyValue lists
I would not worry about the GSS run not passing but the checker framework needs to be fixed |
@davecramer Yes - noticed this failed in the CI tasks and it was fixed - should be passing, but the workflow needs approval for it to run (it passes locally) |
@davecramer we have been recently working on migrating from Oracle to Postgres, and today we find out that unique keys are handled totally different between each engine... this leads me to think that this PR is not valid since I was under the assumption that Unique indices would enforce uniqueness even for null values, but this is not the case (like Oracle does). e.g. Having table (id1 int not null, id2 int null, value int null) with unique index on id1, id2 them allows to have rows {1,null,10},{1,null,20},etc... this was not the case in Oracle - so this change would actually now be updating all of those entries instead of just the one... this will need to be re-visited and patched accordingly |
@davecramer I've updated the code to include your logic for nullable columns and prevent the usage of those for updateable result sets. It may be possible to allow and just have the logic to equals to the values, which would never match for null scenarios... however, this would introduce a bad user experience since we say it is updateable but there are no updates possible. Just realized that the logic added to check for |
…ith nullable columns Adding logic to ensure all columns in the constraint (primary/unique) are non-nullable (always true for PKs) to guarantee 1-1 updates
No need to have IS NULL when nullable keys are not allowed to guarantee 1-1 updates
pgjdbc/src/main/java/org/postgresql/jdbc/PgDatabaseMetaData.java
Outdated
Show resolved
Hide resolved
Indices with expressions cannot be used (unless expression parsing / resolution is implemented properly - currently don't see a way to get individual list elements from pg_index.indexprs to enable proper expression filtering (pg_get_expr gives the expression, but unable to map this to a specific attribute in the index)
Recently was also attempting to create an index on the table without a constraint but using expressions to make it not-null so that uniqueness is enforced, and found out that this would be causing problems in the logic. Added logic to exclude the indices that have expressions - other option would be to only allow indices that have a constraint linked to the table (using pg_constraint table in JOIN) - I think it would be possible to support such expressions, but I am unaware on how to extract the specific expression for the attribute (since indexprs is a 'LIST' of expressions, but cannot see how to get individual elements from it so that those could be mapped to the proper attrs of the table) |
psql -E can give you a lot of information :) |
@chalmagr so do you consider this complete ? I'd like to push this and get a release out soon(ish) |
Need to commit to master as well |
@davecramer Sorry - been a bit off recently :) - yes, I think this is complete and it seems to be working so far - using expressions will be quite tricky to do as not only we would need to figure out which columns are used, but when building the where condition it would need to re-create the expression and match the value that would also be an expression... I think this is just too much |
@chalmagr It has been released in 42.2.24. Thanks! |
All Submissions:
Changes to Existing Features: