Minor updates to support UPDATE ... FROM in Doltgres
#3016
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Minor changes to support
UPDATE ... FROMin Doltgres (dolthub/doltgresql#1536)While working on this, I noticed a few issues with the
UPDATE ... JOINsupport in GMS:UPDATE ... JOINinPlanBuilder.buildUpdate()and in the analyzer rulemodifyUpdateExprsForJoin. Not allUPDATE ... JOINstatements can be handled in PlanBuilder, because some statements, likeIN SUBQUERY, are transformed into a join during analysis, so we need logic in the analyzer to identifyUPDATE ... JOINplans after that transformation. To reduce the duplication, I removed the logic from PlanBuilder and now we rely on on themodifyUpdateExprsForJoinrule to mark allUPDATE ... JOINplans.plan.GetUpdatable()to get a reference to the table being updated, butUPDATE ... JOINcan update multiple tables. TheGetUpdatable()APIs should be refactored to model this, otherwise we cannot accurately track multiple tables being modified and apply all the correct triggers/constraints.UPDATE ... JOINnever honors foreign key constraints, due to limitations in the concrete typeUpdateJoin.GetUpdatable()returns. TheupdatableJoinTabletype does not implementsql.ForeignKeyTable, so GMS is unable to load any foreign key constraints from it. This also needs to be handled in a future PR.