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 ... FROM
in Doltgres (dolthub/doltgresql#1536)While working on this, I noticed a few issues with the
UPDATE ... JOIN
support in GMS:UPDATE ... JOIN
inPlanBuilder.buildUpdate()
and in the analyzer rulemodifyUpdateExprsForJoin
. Not allUPDATE ... JOIN
statements 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 ... JOIN
plans after that transformation. To reduce the duplication, I removed the logic from PlanBuilder and now we rely on on themodifyUpdateExprsForJoin
rule to mark allUPDATE ... JOIN
plans.plan.GetUpdatable()
to get a reference to the table being updated, butUPDATE ... JOIN
can 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 ... JOIN
never honors foreign key constraints, due to limitations in the concrete typeUpdateJoin.GetUpdatable()
returns. TheupdatableJoinTable
type 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.